Hacker News Reader

Comment by jprete | Hacker News Reader

I think whitespace handling is a problem, but not the only one. Shell data structures are awful and confusing, so best avoided. Error handling is also subpar, requiring boilerplate for every reasonable error situation. And there’s a constant need to be careful about stdout va stderr and how exactly a function returns data.

I find moving to even Python to be an inadequate answer, because the shell does two crucial things very very well - it manipulates the filesystem and runs commands in their most native format. And even Python is very cumbersome at those two tasks.

But sometimes you need good data structures/execution flow control, and good filesystem/command control, at the same time.

Intuitive, consistent, predictable whitespace handling would fix a lot of shell scripting problems, though.

(I haven’t given Powershell a serious shot, maybe I should.)

View on HN

This is the #1 reason I enjoy using the plan 9 rc shell[1] for scripts. There's exactly one place where word splitting happens: at the point where command output is evaluated. And there, it's trivial to use any character you want:

    x = `{echo hi there: $user}  # evalutates to list ('hi' 'there:' 'ori')
    y = `:{echo hi there: $user} # evalutates to list ('hi there' ' ori')

There's no other word splitting, so:

    args = ('a' 'b c' 'd e f')
    echo $#args
    echo $args(3)

will print:

    3
    d e f

The shell itself is pleasantly simple; there's not much to learn[2]. And while it's not fun for interactive use on unix because it offloads too much of the interactive pleasantness to the plan 9 window system (rio), it's still great for scripting.

[1] http://shithub.us/cinap_lenrek/rc/HEAD/info.html

[2] http://man.9front.org/1/rc

> I find moving to even Python to be an inadequate answer, because the shell does two crucial things very very well - it manipulates the filesystem and runs commands in their most native format. And even Python is very cumbersome at those two tasks.

Thankfully Perl exists.

Perl is better than Python at being an improved shell.

In Perl, you can use backticks to execute commands for example

Ruby too. And there's the FileUtils lib in ruby that mimics common Unix command like mv, cp, ls, mkdir

I find myself using `Pathname` a lot more often than I use `FileUtils`

Same for me with Dir vs FileUtils.ls

The globbing support dir has is wonderful

Powershell is worth a deeper look if you have time. It can be odd "at first glance", especially trying to do things you know from other shells, but it does have a lot more data structures available for use in the shell, a different mostly predictable approach to error handling (including try { } catch { } just like a "real" language), a standardized arguments parsing model for its own commands and cmdlets (though you'll still likely be using lots of DOS or Unix commands with their own bespoke argument parsing, as usual), and now that Powershell is open source and cross-platform it is more useful than ever.

Powershell is good, but one downside is that you have to explicitly check the exit code of each external program called and stop the script yourself for non-zero exit codes if that's what you want to do. Ie. there's no "set -e".

You can make a helper function or commandlet of course, but it obfuscates the code and is a pain to distribute around always where needed. They argue that non-zero exit codes for errors in external programs is a convention that doesn't exist consistently where Powershell is used. OK, but all the programs I use do follow that convention and so I find that very painful.

Yeah, DOS/Windows applications have used for some long number of years non-zero return codes for a lot more complicated things than just "error" but also "type of success". The documentation on Robocopy is an interesting example.

PowerShell's default handling for native commands is treating anything written to stderr as signaling an error, which is somewhat more reliable for old DOS/Windows commands (but not necessarily reliable for some Unix commands that use stderr as a secondary logger for various reasons including because they expect stdout to pipe redirected more often than not). Though you need to set $ErrorActionPreference [0] to something other than "Continue" to notice this behavior.

However, since Powershell 7.3 there is also a setting you can temporarily change to treat non-zero returns as errors: $PSNativeCommandUseErrorActionPreference [1]. Note that as its name suggests you need to set $ErrorActionPreference to something useful for it to work as you intend.

[0] https://learn.microsoft.com/en-us/powershell/module/microsof...

[1] https://learn.microsoft.com/en-us/powershell/module/microsof...

Take a look at Oil Shell?

https://www.oilshell.org/

Given your comments you need to try xonsh - this is a python shell.

You can call pure python plus it has the simple running of command like other shells.

Perhaps I need to give that a serious try at last. I don’t dare touch a shell other than bash or zsh because you’ll have to come back to those anyway, for example for debugging containers. Then another shell is another thing to learn, configure but most importantly go wrong.

I currently use zsh and quickly drop into IPython when needed.

I use declare in a lot of my bash scripts for associative arrays and some other stuff. It can make scripts easier to read/reason about IMO. Something useful to learn if you’ve never heard of it.

https://linuxhint.com/bash_declare_command/

like, the || && operators having same precedence.. and other inconsistencies, i.e. how to pass "a*" down as parameter..

btw csh/tcsh "" quoting rules are atrocious, avoid it..

Reply on news.ycombinator.com