Hacker News Reader

Comment by lisper | Hacker News Reader

I'm sorry, but anything that requires a programmer to memorize this many rules in order to avoid shooting themselves in the foot is deeply and fundamentally flawed and needs to be completely redesigned from the ground up. There is a reason that modern programming languages include actual data strutures and don't just treat everything as a string of bytes. That might have been a good idea in 1973. In 2023, not so much.

So... use a shell for interactive work if you must, but never ever write a script for one. Use Python or Ruby or just about anything besides a shell.

View on HN

>"but never ever write a script for one. Use Python or Ruby or just about anything besides a shell."

And create a massive overhead because these python scripts just keep on breaking? No thanks, shell has its issues but saying not to use them anymore in simple scripts any to much of a hot take for me. (but please note this is a very biased take on my park)

Unless you're of course only want to use perl scripts... those things will keep on running for decades without ever breaking (or being readable)

If you keep to basic functionality, there are very few breaking changes in both Python and Ruby. Apart from py2/3 and ruby string encoding change, I have not run into anything I remember now. I've experienced more issues with tiny differences between zsh/bash/ash/dash. (And Mac vs modern bash)

Except the python3 str change was pretty big (and centered again, on those things that aren't just strings in POSIX).

Getting the correct `bytes` that went in your program uses completly different interfaces compared normal python use , for example, you now need to use `os.environb` instead of `os.environ` if you want to use arbitrary POSIX-compliant `bytes` environment variables and `argvb = [os.fsencode(a) for a in sys.argv]` instead of just `argv` for POSIX-compliant `bytes` command line arguments.

As people suggest in https://peps.python.org/pep-0383/ , handling really arbitrary inputs is tough work.

Python 3 took about a decade to play out and for a few years you could opt to still explicitly use v2. Parent was saying those scripts "keep on breaking". Those two things are not the same.

A lot of languages/systems require to memorize rules. And a basic understanding on how the shell works help understanding those rules. They aren't just magic incantation.

As an older programmer, I've noticed that the unix shell is one of these few tools that I learned when I was a teenager that is still relevant and useful today (and unavoidable, even if you don't like it). So understanding it was (and still is) a good investment.

The shell rules can be called many things but "basic" is not one of them.

The flaw in your reasoning is that a minimal POSIX shell, in the form of dash, compiles to less than 100k bytes on 32-bit x86.

None of the other technologies that you did or might mention exhibit this property.

Korn features were explicitly excluded to meet this goal in the standard.

There's also the set & setting that is good to consider. For example, I bet lots of the scripts in my current employer's DevOps infrastructure have filename handling bugs that could've been avoided by meticulously following these rules. But these scripts are not meant to be used by customers - the people using these scripts are other developers working on the product wanting to set up the development environment. The script might fail if you do some stupid / unexpected stuff, even as simple as having a space in your Unix user name (i.e. home directory path) or VCS clone directory.

I would feel weak from the knees if someone exposed these scripts on a web server and let them process input from untrusted external parties. Yet, I don't care if the scripts aren't 100% perfect if they work as long as the user doesn't do something silly. Plus, many of them are portable meaning you can run them out of the box on Linux, MacOS or WSL (Windows) without installing any extra software.

I have literally never worked on a computer where that would make a noticeable difference.

I am however struggling with those footguns regularly.

I actually used Microsoft Xenix on 80286 "minis" early in my career.

The 64k limit for the text segment of a compiled C program is likely a large factor in the POSIX shell standard; it seems designed to fit architectures similar to this.

The Korn shell was included in later versions of Xenix, but I understand that the source code was an unmaintainable mess, hence the removal of features in the final standard for the shell language.

Most home routers have < 16MB of space.

Micropython will compile to much less than 100k bytes on x86, too.

You should try to get that into Busybox!

But is micropython installed on my router (POSIX shell is)?

Unironically Powershell. I agree with you, I don't get how people can justify having a string of bytes and then parsing that to communicate between programs. Powershell functions off of data types. You can so ls (an alias for Get-ChildItem). You can also do (ls).CreationTime, just like in most languages since it returns an object. Or (ls)[0].Name, since just like you would expect, it returns an array of objects. Or do ls | select-object Name, CreationTime. And grab those variables out of the object. And when you pass things, it passes an object. Much safer, much easier, whether Powershell or something else, this idea is the future of terminal.

Just port PowerShell to Linux, and Bash and friends will become obsolete.

EDIT: seems like that has already happened: https://learn.microsoft.com/en-us/powershell/scripting/insta...

It's not on my desktop (not installable via my distro), not on my laptop (same), not on my router (same, and it's a completely different one!), not on my phone, not on any of the servers I interact with (and again, not installable!)...

Given it's harder to get than (as an example) Python (which is likely already on the system I'm interacting with), and powershell just straight breaks things (https://github.com/PowerShell/PowerShell/pull/1901), why would I ever use powershell?

The porting of PowerShell happened, Bash obsolescence is still uncertain.

I would agree. It would be nice to see a new shell (that isn't PowerShell) that worked well with spaces in file names.

Zsh works fine with spaces and all other manner of weird whitespace, non-printable binary data, etc. The only unfortunate edge case where are you still need to quote things defensively is if a parameter is completely empty, then the entire word gets removed from the command if the expansion is not quoted.

Other shells are fun, but Z Shell already solved all the worst problems of parameter expansion years ago. If anything, you should be migrating your Bash scripts to Zsh even if you never switch your interactive shell.

That said, most of the problems here don't have much to do with parameter expansion and have more to do with the fact that text as a universal interface kind of sucks. Nushell and Powershell have better models here, but the latter lacks a convenient way to parse fixed-width tables so it's unfortunately frustrating to use with a lot of traditional Unix tools (there's no "ConvertFrom-Table" cmdlet, only "ConvertFrom-CSV").

> Zsh works fine with spaces and all other manner of weird whitespace, non-printable binary data, etc.

> most of the problems here don't have much to do with parameter expansion

Parameter expansion is 99% of the problem here as you said youself.

Parameter expansion ends up being most of the time what other script languages would call eval, and everyone knows to avoid eval unless you really need to use it.

Excluding some really annoying bugs, almost all shells works fine for any sort of binary data. It's the user shell script that is composed of unsafe word expansions that doesn't.

It just takes someone messing with parameter expansion in zsh (SH_WORD_SPLIT) and then zsh becomes just another shell in a world of hurt again.

Reply on news.ycombinator.com