4 ms·

Ask HN: If you could reinvent the Linux shell, what would you do differently?

3 points by ent101 5y ago

billconan 5y ago
I would create a better scripting language than bash script. The syntax will be closer to a normal programming language.
Someone 5y ago
Don’t make the shell expand glob patterns. Move that to a library for tools to call. Advantages: - things like mv *.jpg foo/ work regardless of the number of files matched, avoiding users having to learn find or xargs (https://serverfault.com/questions/315590/how-to-remove-many-200-000-files https://serverfault.com/questions/315590/how-to-remove-many-... - it’s much easier to handle arguments containing spaces and other problematic characters - you can write tools that handle glob patterns differently for some of their arguments without the user having to escape characters Not really shell issues, but contributing to the mess - Be consistent in naming tools and arguments - provide a usable help system (MPW commando is by far the best way I know for letting users compose shell commands. I don’t understand why it hasn’t been replicated) - there should be a standard way to send higher-level data than streams of characters over pipes. Tables, in particular, would be very nice to have because they would allow for easier composition of commands. Hypothetical example: ls foo/ | where filename≈bar.baz | select name,size | max 10 (Powershell is like that, but I would hope there’s a way to do that without going full “send whatever binary data you want: we’ll use reflection to access fields”)
- schoen 5y ago
  I know the text stream interface has lots of limitations and formats are often unspecified or underspecified. I would just add that if you happen to have numbered fields with consistent delimiters (and no quoting or escaping of delimiters), you can do all of these things with cut, sort, grep, and head, to say nothing of awk, which can typically do them in a single line. ls -l foo/ | awk '$NF == "bar.baz" {print $NF, $5}' | head -10 The numbered fields with consistent delimiters part is a big if, and of course the fields are numbered and not named, so you don't get to do the "name,size" thing (you have to know explicitly that for this particular command, the filename is the last field and the size is the fifth field). One direction that some people have gone is to treat JSON as a universal form of structured data (where text is a universal form of unstructured data). You could rebuild many Unix tools or near-equivalents to work well with JSON records instead of, say, lines. Your pipe example would be pretty straightforward in jq if you had a version of ls that gave you JSON outputs. Here's a crummy, primitive version of ls that gives JSON outputs. :-) #!/usr/bin/env python import json, os, sys ret = {} for arg in sys.argv[1:]: here = {} for entry in os.listdir(arg): path = os.path.join(arg, entry) stat = os.stat(path) here[entry] = { "size": stat.st_size, "ctime": stat.st_ctime, "atime": stat.st_atime, "mtime": stat.st_mtime, "uid": stat.st_uid, "gid": stat.st_gid, "mode": oct(stat.st_mode)[2:], } ret[arg] = here print(json.dumps(ret)) With that, you could then use jq to do various kinds of selection and aggregation. (The specific data model here is probably not right yet, because it allows, and requires, exactly one level of subdirectory nesting in each listing.) I'm not sure how the jq learning curve (combined with JSON-refitted Unix tooling) would compare to something like PowerShell, which is super-verbose compared to Unix traditions. Apparently there are several ongoing efforts to create Unix shells that use JSON or other structured data more natively, but I have yet to try any of them. https://ilya-sher.org/2018/09/10/jq-is-a-symptom/ https://ilya-sher.org/2018/09/10/jq-is-a-symptom/ https://github.com/ngs-lang/ngs https://github.com/ngs-lang/ngs (also see the numerous shell projects linked from the NGS GitHub page!)
  - Someone 5y ago
    I know you can do it but the trouble with Unix is that its user interface is horrid (http://www.ceri.memphis.edu/people/smalley/ESCI7205F2009/misc_files/The_truth_about_Unix_cleaned.pdf http://www.ceri.memphis.edu/people/smalley/ESCI7205F2009/mis..., discussed in https://news.ycombinator.com/item?id=9558455 https://news.ycombinator.com/item?id=9558455) The list of inconveniences in the shell is just too long. It is death by a thousand cuts. I’ve seen scripts grabbing file sizes from the output of ls -l by using character offsets in each line, which, aside from the usability issue, means such scripts will break if files get too large to fit the space ls thinks is sufficient.
smt88 5y ago
Arguments before commands. For example, "rm -Rf /" would become "/ rm -Rf". I'd do this for two reasons: 1) it's more common to edit your last command than your last argument, and 2) you can't destroy anything by accidentally hitting return at the wrong moment.

3 points by ent101 5y ago

I would create a better scripting language than bash script. The syntax will be closer to a normal programming language.

Someone 5y ago

Don’t make the shell expand glob patterns. Move that to a library for tools to call. Advantages: - things like mv *.jpg foo/ work regardless of the number of files matched, avoiding users having to learn find or xargs (https://serverfault.com/questions/315590/how-to-remove-many-200-000-files https://serverfault.com/questions/315590/how-to-remove-many-... - it’s much easier to handle arguments containing spaces and other problematic characters - you can write tools that handle glob patterns differently for some of their arguments without the user having to escape characters Not really shell issues, but contributing to the mess - Be consistent in naming tools and arguments - provide a usable help system (MPW commando is by far the best way I know for letting users compose shell commands. I don’t understand why it hasn’t been replicated) - there should be a standard way to send higher-level data than streams of characters over pipes. Tables, in particular, would be very nice to have because they would allow for easier composition of commands. Hypothetical example: ls foo/ | where filename≈bar.baz | select name,size | max 10 (Powershell is like that, but I would hope there’s a way to do that without going full “send whatever binary data you want: we’ll use reflection to access fields”)

schoen 5y ago
I know the text stream interface has lots of limitations and formats are often unspecified or underspecified. I would just add that if you happen to have numbered fields with consistent delimiters (and no quoting or escaping of delimiters), you can do all of these things with cut, sort, grep, and head, to say nothing of awk, which can typically do them in a single line. ls -l foo/ | awk '$NF == "bar.baz" {print $NF, $5}' | head -10 The numbered fields with consistent delimiters part is a big if, and of course the fields are numbered and not named, so you don't get to do the "name,size" thing (you have to know explicitly that for this particular command, the filename is the last field and the size is the fifth field). One direction that some people have gone is to treat JSON as a universal form of structured data (where text is a universal form of unstructured data). You could rebuild many Unix tools or near-equivalents to work well with JSON records instead of, say, lines. Your pipe example would be pretty straightforward in jq if you had a version of ls that gave you JSON outputs. Here's a crummy, primitive version of ls that gives JSON outputs. :-) #!/usr/bin/env python import json, os, sys ret = {} for arg in sys.argv[1:]: here = {} for entry in os.listdir(arg): path = os.path.join(arg, entry) stat = os.stat(path) here[entry] = { "size": stat.st_size, "ctime": stat.st_ctime, "atime": stat.st_atime, "mtime": stat.st_mtime, "uid": stat.st_uid, "gid": stat.st_gid, "mode": oct(stat.st_mode)[2:], } ret[arg] = here print(json.dumps(ret)) With that, you could then use jq to do various kinds of selection and aggregation. (The specific data model here is probably not right yet, because it allows, and requires, exactly one level of subdirectory nesting in each listing.) I'm not sure how the jq learning curve (combined with JSON-refitted Unix tooling) would compare to something like PowerShell, which is super-verbose compared to Unix traditions. Apparently there are several ongoing efforts to create Unix shells that use JSON or other structured data more natively, but I have yet to try any of them. https://ilya-sher.org/2018/09/10/jq-is-a-symptom/ https://ilya-sher.org/2018/09/10/jq-is-a-symptom/ https://github.com/ngs-lang/ngs https://github.com/ngs-lang/ngs (also see the numerous shell projects linked from the NGS GitHub page!)
- Someone 5y ago
  I know you can do it but the trouble with Unix is that its user interface is horrid (http://www.ceri.memphis.edu/people/smalley/ESCI7205F2009/misc_files/The_truth_about_Unix_cleaned.pdf http://www.ceri.memphis.edu/people/smalley/ESCI7205F2009/mis..., discussed in https://news.ycombinator.com/item?id=9558455 https://news.ycombinator.com/item?id=9558455) The list of inconveniences in the shell is just too long. It is death by a thousand cuts. I’ve seen scripts grabbing file sizes from the output of ls -l by using character offsets in each line, which, aside from the usability issue, means such scripts will break if files get too large to fit the space ls thinks is sufficient.

smt88 5y ago

Arguments before commands. For example, "rm -Rf /" would become "/ rm -Rf". I'd do this for two reasons: 1) it's more common to edit your last command than your last argument, and 2) you can't destroy anything by accidentally hitting return at the wrong moment.