undefined

points

[-]

That’s not correct because POSIX passes what is ostensibly an array of strings.

Windows, on the other hand, only passes one string. So it’s up to the application to choose how to handle whitespace, quotation marks, and other nuances with parsing parameters.

Variable expansion in Bash is lazy. But there’s no reason why variables cannot be tokenised so that strings with spaces aren’t treated as multiple parameters. And in fact that’s exactly how some other shells work, such as the one I maintain.

by CodesInChaos3 hours ago|

parent|

[-]

While unix handles splitting into an array of strings, it still leaves parsing those strings up to the application. One of the bigger problems is the ambiguity caused by filenames starting with `-`. Some applications support the `--` marker to end such parsing, but it's inconsistently implemented and the caller has to actively remember to use it.

A typed array (e.g. by having a required single byte marker at the start of each string), or even nested structures similar to s-expressions would have avoided this.

by hnlmorg1 hours ago|

parent|

[-]

Funny enough, I’ve actually spent a long time trying to figure out how to solve this problem in murex but it always comes back to the same problem: anything smart I implement into the shell is immediately lost the moment I call fork().

I even considered writing a wrapper around some commands to send -- regardless of whether the user includes it or not. But that’s error prone too because

1. it’s a GNUism so you can’t guarantee compatibility with any tools that don’t call GNUs flag parsing library (which is particularly problematic outside of Linux)

2. If there a file called “-f” (for example), how do you know if the user intended that to be called as a file reference or a command flag? You then need to bake in a bunch of additional syntax sugar to make that explicit. Which results in a pretty awful user experience

3. The maintenance overhead for this would be astronomical

If UNIX were designed from day one to have that parameter type passed then this would be a very simple problem to solve. But the PDP machine UNIX was originally designed to run on wouldn’t have been powerful enough for that anyway. So once again we are limited by an architecture designed to run on mid-range systems of the 1970s.

by formerly_proven9 hours ago|

prev|

[-]

Array of arguments is vastly superior and more secure than every program/runtime inventing a slightly different way of splitting a command string into an array of arguments. No debate. A real problem is the related birth defect in ssh2.

by akoboldfrying9 hours ago|

prev|

[-]

Well, the only other way I can think of that it could be done is the Windows way, whereby you pass the unparsed command line, spaces and all, as a string to the new process. And while this is arguably the cleaner interface, in practice it has meant even worse quote handling, since how -- or even whether -- double quotes are parsed now depends on the probably undocumented process startup code chosen by the program's compiler vendor.

Want to quote a command line that may already contain double quotes, in order to pass it as an argument to some other program? No, you don't. It isn't right to want that.

by ChrisSD7 hours ago|

parent|

[-]

The other other way would be more structured. Arguments are not just an array, they also contain `--switch` and key/value pairs (e.g. `--key value` or `--key=value` depending on who you ask). One problem with the flat array approach is there's no way to distinguish a literal value starting with `-` from a switch, which means there needs to be some way to workaround that (and users have to remember the workaround; how often do people remember to use `rm -- "$FILENAME"`).

In practice almost every application does still need to do its own parameter parsing; a flat array is not enough.

by sysguest9 hours ago|

prev|

[-]

yeah but... that convention is so much of a security/bug headache

sometimes, its footguns seem worse than javascript...

hope some typescript-like "typed shell" becomes mainstream someday

by coldpie8 hours ago|

parent|

[-]

> hope some typescript-like "typed shell" becomes mainstream someday

The trouble with trying to invent a new, more robust shell language is you basically just end up re-inventing any number of scripting languages (eg Perl, Python, awk, ...), so you might as well use one of those.

by hnlmorg8 hours ago|

parent|

[-]

Most regular programming languages aren’t well suited for shells because they have a verbose syntax due to their readability goals. But with a shell, the vast majority of times you’re typing in stuff that you have no intention of reading back ever again.

I’ve done a fair amount of research here and I actually think we do need a new programming language for the shell (and then I created one).

I wrote a blog about this problem: https://murex.rocks/blog/split_personalities.html#conclusion

by coldpie7 hours ago|

parent|

[-]

Excellent article, thanks for the link. I do agree with the premise. But every time I write some Bash code and think there should be a better way to do this, I ask myself why I don't just learn Perl. I dunno. Feels like inventing another solution would just hit the old "there are now 14 standards" problem where it would solve some problems but introduce others (see: PowerShell).

by hnlmorg7 hours ago|

parent|

[-]

I don’t disagree with you per se. But if the new shell solves enough annoying problems then I think it has merit in existing.

by ravenical7 hours ago|

parent|

prev|

[-]

> hope some typescript-like "typed shell" becomes mainstream someday

Might want to check out nushell (https://www.nushell.sh/)

by colejohnson665 hours ago|

parent|

prev|

[-]

PowerShell