5 ms·

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 fla

by lisper 3y ago

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.

ape4 3y ago
I would agree. It would be nice to see a new shell (that isn't PowerShell) that worked well with spaces in file names.
- nerdponx 3y ago
  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").
  - ElectricalUnion 3y ago
    > 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.
Woeps 3y ago
>"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)
- viraptor 3y ago
  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)
  - ElectricalUnion 3y ago
    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/ https://peps.python.org/pep-0383/ , handling really arbitrary inputs is tough work.
    - viraptor 3y ago
      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.
yodsanklai 3y ago
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.
- pdimitar 3y ago
  The shell rules can be called many things but "basic" is not one of them.
deleted 3y ago
[deleted]
chasil 3y ago
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.
- sudosysgen 3y ago
  Micropython will compile to much less than 100k bytes on x86, too.
  - chasil 3y ago
    You should try to get that into Busybox!
  - aragilar 3y ago
    But is micropython installed on my router (POSIX shell is)?
- vesinisa 3y ago
  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.
- wodenokoto 3y ago
  I have literally never worked on a computer where that would make a noticeable difference. I am however struggling with those footguns regularly.
maldev 3y ago
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.
Detrytus 3y ago
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/install/installing-powershell-on-linux?view=powershell-7.3 https://learn.microsoft.com/en-us/powershell/scripting/insta...
- inejge 3y ago
  The porting of PowerShell happened, Bash obsolescence is still uncertain.
- aragilar 3y ago
  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 https://github.com/PowerShell/PowerShell/pull/1901), why would I ever use powershell?

by lisper 3y ago

ape4 3y ago

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

nerdponx 3y ago
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").
- ElectricalUnion 3y ago
  > 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.

Woeps 3y ago

>"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)

viraptor 3y ago
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)
- ElectricalUnion 3y ago
  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/ https://peps.python.org/pep-0383/ , handling really arbitrary inputs is tough work.
  - viraptor 3y ago
    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.

yodsanklai 3y ago

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.

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

deleted 3y ago

[deleted]

chasil 3y ago

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.

sudosysgen 3y ago
Micropython will compile to much less than 100k bytes on x86, too.
- chasil 3y ago
  You should try to get that into Busybox!
- aragilar 3y ago
  But is micropython installed on my router (POSIX shell is)?
vesinisa 3y ago
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.
wodenokoto 3y ago
I have literally never worked on a computer where that would make a noticeable difference. I am however struggling with those footguns regularly.

maldev 3y ago

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.

Detrytus 3y ago

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/install/installing-powershell-on-linux?view=powershell-7.3 https://learn.microsoft.com/en-us/powershell/scripting/insta...

inejge 3y ago
The porting of PowerShell happened, Bash obsolescence is still uncertain.
aragilar 3y ago
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 https://github.com/PowerShell/PowerShell/pull/1901), why would I ever use powershell?