Hacker News Reader

Comment by mirekrusin | Hacker News Reader

GNU Guile [0] is pretty cool.

Is Guile really that good at the shell scripting "thing"? Like, the bash superpower is that it makes it extremely easy to run subprocesses in incredibly flexible ways (in the background, foreground, in pipelines, with stdout/stderr redirected to files, etc. etc.). Can Guile do that smoothly? I generally find that doing things like this is way more awkward in most "real" programming languages compared to shell scripting languages.

I know I’m in my own little corner, but stringing process together is the shell/unix superpower.

The “Unix way” stands on the shoulders of stdin, stdout, pipe, and fork.

And the shells make that a first class concept. Breaking up the command line and linking processes together is the #1 job of a shell, everything else is gravy.

The scheme and lisp shell takes fail here, just because you have to go through the gymnastics of syntax.

My fantasy would be to have something like this:

  (! ls | (myfunc) | sort -r -n | >list)
  (“100 x.txt” “200 y.txt”)

Piping system commands into my own functions within the environment.

Sure, I could do:

  ls | myfunc.scm | sort -r -n

But then I can do that with anything, not just scheme (there’s that Unix superpower again).

So basically using the shell of something like Xerox's PARC Interlisp-D and threading macros.

I would be something like this,

    (->
       ls
       myfunc
       sort -r -n
       (> list))

Followed by "Select => Execute" with the mouse, or "Execute last form" with keyboard shorcut.

You also have to go through gymnastics of syntax to write a shell program that anyone could reliably use on any data, with any file names.

  $ txr
  This is the TXR Lisp interactive listener of TXR 299.
  Quit with :quit or Ctrl-D on an empty line. Ctrl-X ? for cheatsheet.
  Poke a few holes in TXR with a fork before heating in the microwave.
  1> (flow (glob "/proc/*") (take 10))
  ("/proc/1" "/proc/10" "/proc/101" "/proc/102" "/proc/103" "/proc/104"
   "/proc/107" "/proc/1074" "/proc/1086" "/proc/11")
  2> (flow (glob "/proc/*") (take 10) (map (op trim-left "/proc/")))
  ("1" "10" "101" "102" "103" "104" "107" "1074" "1086" "11")
  3> (flow (glob "/proc/*") (take 10) (map (op trim-left "/proc/")) (sort @1 : toint))
  ("1" "10" "11" "101" "102" "103" "104" "107" "1074" "1086")
  4> (flow (glob "/proc/*") (take 10) (map (op trim-left "/proc/")) (sort @1 greater toint))
  ("1086" "1074" "107" "104" "103" "102" "101" "11" "10" "1")

How about we parse digit sequences out of the path names and combine them with the originals, then sort on those digit sequences turned into integers:

  5> (defun get-nums (str)
       (flow str (tok #/\d+/) (map toint)))
  get-nums
  6> (flow (glob "/proc/*") (take 20) (csort @1 greater get-nums))
  ("/proc/11170" "/proc/11169" "/proc/1222" "/proc/1199" "/proc/1198"
   "/proc/1194" "/proc/1133" "/proc/1104" "/proc/1086" "/proc/1074"
   "/proc/117" "/proc/107" "/proc/104" "/proc/103" "/proc/102" "/proc/101"
   "/proc/12" "/proc/11" "/proc/10" "/proc/1")

csort is caching sort: it caches the result of the key function through which the elements are projected to form the argument of the comparison. In other words, so we don't wastefully call get-nums multiple times for the same path.

Lacking it seeming helpful, it shows a largely invoked valley even I notice some beings can locate.

I guess we should distinguish "the shell environment" (which might stay Bash) with "the shell script language" (which could be any one of a number of options, just use the right hashbang header)

One that strove to do both WOULD have to do all the things you suggested as well (job management, stdout/stderr redirection etc.) So options like oil shell, nushell, fish etc.

I was just talking about "a commandline tooling language" in general, as far as use-cases. And for that, Lua (and Moonscript, which compiles to Lua but is way nicer and has been featured on HN a few times over the years) seems to fit the bill (1-based indexing aside, ugh)

Can you expand on using Guile for shell scripting?

I was aware of it, but not familiar until I looked at the link you shared. Looks like a Scheme, which for the uninitiated is a different approach for shell scripts.

Yes, there are some basic examples here [0] – otherwise it's just shebang and you're good to go; it can be a rabbit hole where you start liking it too much than what you really should (you wanted simple scripts, now you are finishing scheme book).

It's consistent, "infinitely" terse (you can create dsl-like apis for your problem domains), proper programming language.

First time I used it for scripting was when I had to process some xmls and do bunch of processing and gluing together – I was impressed how quick and easy it was without knowing anything about it and how readable the whole thing ended up being.

[0] https://www.gnu.org/software/guile/manual/html_node/Scriptin...

I love that in Guix, Guile is used as the configuration language all the way "from the metal" (the bootloader) to the declarative environment config in userspace.

I'm one of those folks that still can't do LISPs though. If there was a way to replace some or all of the parens with significant indentation instead (which I believe Racket makes possible... but that only works in Racket), I might reconsider it.

You probably heard this one before. After a while the parens do disappear. When conventionally indented, lisp users see only the indentation and not the parens.

With structural editing, no one ever have to match parens or count parens at the end...

YMMV ofcourse.

Reply on news.ycombinator.com