[HN Gopher] Moreshell tricks: first class lists, jq, and the es ...
       ___________________________________________________________________
        
       Moreshell tricks: first class lists, jq, and the es shell
        
       Author : alurm
       Score  : 25 points
       Date   : 2025-08-07 14:46 UTC (8 hours ago)
        
 (HTM) web link (alurm.github.io)
 (TXT) w3m dump (alurm.github.io)
        
       | jeffrallen wrote:
       | I review shell scripts from beginner ops people. I would not
       | approve any of this stuff. Once you need this complexity in
       | shell, you need other things you should be getting from the
       | language's stdlib. So I'd ask them to switch to Python or Go.
       | 
       | Do not fall into the trap of big complex shell scripts.
        
         | zhouzhao wrote:
         | >Do not fall into the trap of big complex shell scripts
         | 
         | This so much.
        
         | SoftTalker wrote:
         | There's a point where what you say is true but I would not view
         | using 'jq' to tease a list out of some JSON data to be it.
         | Isn't that what your python or go code is going to do? All jq
         | is is a packaged set of calls to stdlib stuff.
         | 
         | Systems admins are generally not Python or Go experts. And
         | those are two dependencies which may not be available anyway
         | (or will require installation, and maintenancee, may introduce
         | new vulns, etc.). You could say the same about 'jq' though.
        
         | calmbonsai wrote:
         | I'll go further.
         | 
         | Shell is great for personal or local-group/team automation, but
         | outside of a bootstrap, it should _never_ be used for anything
         | in deployed production.
         | 
         | The 3 main issues are hidden deps, error handling, and
         | performance.
        
         | floydnoel wrote:
         | Overall I agree, but I think developers usually err the other
         | way, where they are afraid of running any shell commands
         | outside of invoking their developer tools.
         | 
         | I really enjoyed this article because I found it refreshing- it
         | felt like it was intended for hackers. I love to learn more
         | about different shells and functionality vs yet another
         | unicorn's latest product announcement.
        
       | delta_p_delta_x wrote:
       | I was about to comment with my usual 'why not PowerShell', but it
       | seems the author acknowledges this anyway at the end:
       | 
       | > I'll quote Rich's sh (POSIX shell) tricks to end this:
       | 
       | > I am a strong believer that Bourne-derived languages are
       | extremely bad, on the same order of badness as Perl, for
       | programming, and consider programming sh for any purpose other
       | than as a super-portable, lowest-common-denominator platform for
       | build or bootstrap scripts and the like, as an extremely
       | misguided endeavor
        
         | alurm wrote:
         | Yeah, PowerShell and nushell are pretty cool, I hope they gain
         | more adoption.
        
           | stouset wrote:
           | I keep intending to give nushell a serious try, but I'm too
           | set in my ways :(
        
         | packetlost wrote:
         | This is why I use Plan9's rc shell for a lot of my scripting
         | needs. It's _dramatically_ nicer to write but even more nice to
         | read.
        
       | its-summertime wrote:
       | with bash namerefs, having a function like
       | split-on-ddash outputa outputb a b c -- x y z         for x in
       | "${outputa[@]}"; do # ...
       | 
       | becomes feasible. Of course, don't do it.
        
         | alurm wrote:
         | Sure.
         | 
         | I have tried Bash namerefs. I found them to be kinda awkward,
         | since you need to name them uniquely. So, you have to pretend
         | that they are global variables, even though they are declared
         | inside a function, which makes their usage verbose.
         | 
         | Here, this could look like:
         | split_by_double_dash() {         declare -n
         | split_by_double_dash_before=$1         declare -n
         | split_by_double_dash_after=$2
         | split_by_double_dash_before=()
         | split_by_double_dash_after=()              ...       }
        
       | chubot wrote:
       | _let's implement split-by-double-dash, a function (or a program)
       | that would return two lists: args that come before -- and ones
       | that come after._
       | 
       |  _split-by-double-dash a b c -- d e f should return the lists [a,
       | b, c] and [d, e, f]_
       | 
       | FWIW in YSH (https://oils.pub/ysh.html), you can do this in a
       | style that's like Python and JavaScript, but you can also combine
       | it with shell idioms.
       | 
       | First create it and pretty print it:                   ysh-0.34$
       | var li = :| a b c -- d e f |  # shell word style, ['a', 'b']
       | style is also accepted              ysh-0.34$ = li  # pretty
       | print with =         (List)  ['a', 'b', 'c', '--', 'd', 'e', 'f']
       | 
       | Then test out the indexOf() method on strings:
       | ysh-0.34$ = li.indexOf('--')         (Int)   3
       | 
       | Then write the function:                   ysh-0.34$ func
       | splitBy(li) {                 >   var i = li.indexOf('--')
       | >   assert [i !== -1]                 >   return ( [li[ : i],
       | li[i+1 : ]] )  # same slicing as Python                 > }
       | 
       | Call it and unpack it                   ysh-0.34$ var front, back
       | = splitBy(li)              ysh-0.34$ = front         (List)
       | ['a', 'b', 'c']
       | 
       | Use it in shell argv, with @myarray as splicing:
       | ysh-0.34$ write -- @back         d         e         f
        
         | alurm wrote:
         | YSH looks very nice here, thanks. I thought to mention YSH, but
         | have no experience with it, so I hoped you would comment.
         | 
         | (I guess we're duplicating threads at this point :D)
        
       | kjellsbells wrote:
       | I know Perl gets no love here, and for good reason sometimes, but
       | I have a hard time believing that code full of syntactical
       | characters like                 if .["found"] then         . |
       | .after += [$arg]       elif $arg == "--" then         . | .found
       | = true       else         . | .before += [$arg]       end
       | 
       | or                 for (i = $indicies) if { ~ $*($i) -- } {
       | before = <= {       ...
       | 
       | ...is more readable and maintainable than:                 my
       | ($before, $after) = split /\s*--\s*/, $input;       my @list1 =
       | split ' ', $before;       ...
        
       ___________________________________________________________________
       (page generated 2025-08-07 23:02 UTC)