6 ms·

GNU utilities have addressed this problem for a long time. Maybe he's on OS X? You can install them there though. You don't need anything like PowerShell. H

by chubot 7y ago

GNU utilities have addressed this problem for a long time. Maybe he's on OS X? You can install them there though. You don't need anything like PowerShell. His cut -sf 2 -d \| can be written cut --only-delimited --fields 2 --delimiter '|' Likewise xargs -L 1 -I % jira attach rm % can be rewritten xargs --max-lines=1 --replace=% -- jira attach rm % These are options are easy to find with cut --help and xargs --help. Or 'man cut and 'man xargs'. (Though honestly it's weird that xargs doesn't accept --max-lines 1, only --max-lines=1 ? ) --- I plan to add a mode to http://www.oilshell.org/ http://www.oilshell.org/ to support longopts in all the builtins, e.g. instead of read -r -d ',' instead of read -raw -delimiter ',' I wrote a blog post last night that shows other benefits you can try now: Oil's Stricter Semantics Solve Real Problems http://www.oilshell.org/blog/2019/08/16.html http://www.oilshell.org/blog/2019/08/16.html

kmdupree 7y ago
yep. I know about the -- way of specifying the args. I'm not saying that we can't do better with existing tools, just that we don't do better.
- chubot 7y ago
  I think your post is conflating two questions: (1) Whether tools support long options, and (2) Whether script authors use long options And its claims about #1 seems inaccurate to me. I haven't seen any tools that support only short options in a LONG time. For example, try pip --help or virtualenv --help. Or any tool written in Go, or node.js, etc. I always support long options myself, e.g.: https://github.com/oilshell/oil/blob/master/test/sh_spec.py#L1045 https://github.com/oilshell/oil/blob/master/test/sh_spec.py#... The only case where you don't have long options if you're trying to limit yourself to POSIX, which not many people do, and which I don't recommend for this reason (among others). ----- I agree with the gist of your post regarding #2 -- people should use long options more. But there's very straightforward and actionable advice that can go at the very top. They don't have to wait for #1, because it already happened. You can and should just start using them in your bash scripts! You don't need to switch shells, switch languages, or even change the tools you use. Based on this thread, it DOES appear that many people are confused by this. I'm tempted to write my own blog post, which I may do. But honestly I think a tool that translates short options to long options would be a better solution -- i.e. advocacy through tools rather than advocacy through words. (e.g. "go fmt" seems to have done wonders for formatting without making people read style guides.) This should be pretty straightforward with the Oil parser [1] and I can use help if anyone cares enough :) [1] http://www.oilshell.org/blog/tags.html?tag=parsing-shell#parsing-shell http://www.oilshell.org/blog/tags.html?tag=parsing-shell#par...
Aqueous 7y ago
In the article he talks about the longer flag names. But the commands themselves are inscrutable. 'xargs?' 'cut?' in neither case can you accurately infer from the name what it does. definitely a good pattern to just name things what they do.
- dang 7y ago
  That's only the case for an operator that is rarely used. Once it becomes a primitive of your language, a heavier name gets in the way. You've integrated its meaning now, so you no longer need it explained, but the cost of the extra length continues forever. This is why we don't write, say, "x multiply y". Given this tradeoff, I'd say xargs and cut are good names for those commands: rich enough to convey a large portion of what they do, but short enough to be wieldy and—critically for shells—not to take up too much of a line.
  - liability 7y ago
    I think that argument made sense years ago when people thought completion systems were slow or bloated, but on modern computers anybody who still thinks that way is antiquated or weird. The defaults shells are shipped with are a problem of course, but that could/should be addressed by distro packagers IMHO. Consider the long identifiers used in various modern lisp dialects for instance, particularly scheme dialects. It doesn't bother people because Emacs and vim both have completion systems. A bigger issue with renaming all these utilities is it would negatively impact people who've already learned them. Alienating your existing userbase to appeal to newbies might be in-vogue these days, but I think it's crap.
    - Izkata 7y ago
      Waiting for a completion system breaks the flow of thought, no matter how fast it is. After a certain point, they tend to start getting in the way.
      - liability 7y ago
        Completion fast enough to be faster than a human's reaction time has been feasible for many years now. Furthermore there are completion systems that let you type discontiguous parts of your target word, essentially giving you the best of both worlds.
gregmac 7y ago
I think it's good practice to always use long arguments in (bash) scripts, for the same reason that a variable named `userLastName` is better than one named `str2`. Because you mentioned it, PowerShell has a similar readability issue with positional parameters `Set-Content $file $text` vs `Set-Content -Path $file -Value $text`. In many cases the use and order is obvious, but it's not always (and will vary by person), and inconsistent style in code also makes it harder to read. There's no silver bullet for this stuff. You have to be aware of context and future maintainers: If the vast majority of your code is bash and all maintainers are highly skilled in it, go nuts. If most of your product is in another language and you just have some ancillary install or build scripts in bash/PowerShell/whatever, you should assume people looking at it are closer to the beginner level, and it's better to make things as readable as possible.
- h1d 7y ago
  It's sad when I found out FreeBSD lacks many of the long options I thought was quite obvious. mkdir --parents doesn't work in FreeBSD.
burnte 7y ago
This, plus the fact that a programming language and a command prompt are TWO DIFFERENT THINGS. One is made to be written "once" and then compiled or run many times. The other is a real time interface that should be thoughtful on the amount of effort required by the user to do things, and as such should not take a lot of typing to get things done (and secondarily support scripting).
- madhadron 7y ago
  This is not actually a natural distinction. It's an historical error dating back to OS/360 and JCL (Job Control Language). Fred Brooks, who ran that project, has since claimed it was a mistake. For examples of languages that excel at quick interaction without the failures of shells, look at Rexx and Rebol. Or power up Smalltalk.
  - chubot 7y ago
    Yup, I've noticed that: 1) It's pretty natural to morph shell (OSH) into something like Python. bash already has anemic arrays and dicts -- might as well give them proper syntax and semantics. 2) Python pretty naturally morphs into something like Java (or even ML / OCaml) with MyPy. I statically typed the whole OSH front end recently and it worked well. I don't believe in the artificial barriers between interactive and "compiled" languages. Those two things aren't mutually exclusive. Langauges like C++, Zig, and Jai have Turing-complete interpreters in their compilers. OCaml is normally compiled but it also has a nice REPL that people often use in practice (the type inference helps). So there is really no reason to think of interpreters vs. compilers as separate. Both of them should be interactive. Your compiler should be infinitely fast. ----- I probably won't get to this for years, but I can definitely see a path toward making Oil an efficient compiled language. It almost falls naturally out of the odd "bootstrapping" I'm doing.
    - madhadron 7y ago
      > I don't believe in the artificial barriers between interactive and "compiled" languages. Absolutely. Corman Common Lisp was a great example of this. The REPL compiled to efficient x86 machine code.
myrandomcomment 7y ago
So I could read and understand the first example with no issue. At first I was like “yah!” and then as I read on I realized, “yup, your right it is gobbledygook” Then I read this post and said, “chubot you know, you are correct, but I am to old to learn your new fangled —- stuff”. I cannot tell you the number of times I have mistyped - for — and —- for - over the years without thinking about it. Maybe we should make the command expect both and guess based on what’s after. That would make the CLI better.
- chubot 7y ago
  Yup, Oil will be like Go's flag parser, and accepts one or two dashes! The reason most tools don't is that they allow stuff like rm -rf and tar -xvf, rather than rm -r -f and tar -x -v -f. But that seems to be optimizing for the uncommon case now, given how many tools and flags there are. Nobody can memorize them all!

by chubot 7y ago

kmdupree 7y ago

yep. I know about the -- way of specifying the args. I'm not saying that we can't do better with existing tools, just that we don't do better.

chubot 7y ago
I think your post is conflating two questions: (1) Whether tools support long options, and (2) Whether script authors use long options And its claims about #1 seems inaccurate to me. I haven't seen any tools that support only short options in a LONG time. For example, try pip --help or virtualenv --help. Or any tool written in Go, or node.js, etc. I always support long options myself, e.g.: https://github.com/oilshell/oil/blob/master/test/sh_spec.py#L1045 https://github.com/oilshell/oil/blob/master/test/sh_spec.py#... The only case where you don't have long options if you're trying to limit yourself to POSIX, which not many people do, and which I don't recommend for this reason (among others). ----- I agree with the gist of your post regarding #2 -- people should use long options more. But there's very straightforward and actionable advice that can go at the very top. They don't have to wait for #1, because it already happened. You can and should just start using them in your bash scripts! You don't need to switch shells, switch languages, or even change the tools you use. Based on this thread, it DOES appear that many people are confused by this. I'm tempted to write my own blog post, which I may do. But honestly I think a tool that translates short options to long options would be a better solution -- i.e. advocacy through tools rather than advocacy through words. (e.g. "go fmt" seems to have done wonders for formatting without making people read style guides.) This should be pretty straightforward with the Oil parser [1] and I can use help if anyone cares enough :) [1] http://www.oilshell.org/blog/tags.html?tag=parsing-shell#parsing-shell http://www.oilshell.org/blog/tags.html?tag=parsing-shell#par...

Aqueous 7y ago

In the article he talks about the longer flag names. But the commands themselves are inscrutable. 'xargs?' 'cut?' in neither case can you accurately infer from the name what it does. definitely a good pattern to just name things what they do.

dang 7y ago
That's only the case for an operator that is rarely used. Once it becomes a primitive of your language, a heavier name gets in the way. You've integrated its meaning now, so you no longer need it explained, but the cost of the extra length continues forever. This is why we don't write, say, "x multiply y". Given this tradeoff, I'd say xargs and cut are good names for those commands: rich enough to convey a large portion of what they do, but short enough to be wieldy and—critically for shells—not to take up too much of a line.
- liability 7y ago
  I think that argument made sense years ago when people thought completion systems were slow or bloated, but on modern computers anybody who still thinks that way is antiquated or weird. The defaults shells are shipped with are a problem of course, but that could/should be addressed by distro packagers IMHO. Consider the long identifiers used in various modern lisp dialects for instance, particularly scheme dialects. It doesn't bother people because Emacs and vim both have completion systems. A bigger issue with renaming all these utilities is it would negatively impact people who've already learned them. Alienating your existing userbase to appeal to newbies might be in-vogue these days, but I think it's crap.
  - Izkata 7y ago
    Waiting for a completion system breaks the flow of thought, no matter how fast it is. After a certain point, they tend to start getting in the way.
    - liability 7y ago
      Completion fast enough to be faster than a human's reaction time has been feasible for many years now. Furthermore there are completion systems that let you type discontiguous parts of your target word, essentially giving you the best of both worlds.

gregmac 7y ago

I think it's good practice to always use long arguments in (bash) scripts, for the same reason that a variable named `userLastName` is better than one named `str2`. Because you mentioned it, PowerShell has a similar readability issue with positional parameters `Set-Content $file $text` vs `Set-Content -Path $file -Value $text`. In many cases the use and order is obvious, but it's not always (and will vary by person), and inconsistent style in code also makes it harder to read. There's no silver bullet for this stuff. You have to be aware of context and future maintainers: If the vast majority of your code is bash and all maintainers are highly skilled in it, go nuts. If most of your product is in another language and you just have some ancillary install or build scripts in bash/PowerShell/whatever, you should assume people looking at it are closer to the beginner level, and it's better to make things as readable as possible.

h1d 7y ago
It's sad when I found out FreeBSD lacks many of the long options I thought was quite obvious. mkdir --parents doesn't work in FreeBSD.

burnte 7y ago

This, plus the fact that a programming language and a command prompt are TWO DIFFERENT THINGS. One is made to be written "once" and then compiled or run many times. The other is a real time interface that should be thoughtful on the amount of effort required by the user to do things, and as such should not take a lot of typing to get things done (and secondarily support scripting).

madhadron 7y ago
This is not actually a natural distinction. It's an historical error dating back to OS/360 and JCL (Job Control Language). Fred Brooks, who ran that project, has since claimed it was a mistake. For examples of languages that excel at quick interaction without the failures of shells, look at Rexx and Rebol. Or power up Smalltalk.
- chubot 7y ago
  Yup, I've noticed that: 1) It's pretty natural to morph shell (OSH) into something like Python. bash already has anemic arrays and dicts -- might as well give them proper syntax and semantics. 2) Python pretty naturally morphs into something like Java (or even ML / OCaml) with MyPy. I statically typed the whole OSH front end recently and it worked well. I don't believe in the artificial barriers between interactive and "compiled" languages. Those two things aren't mutually exclusive. Langauges like C++, Zig, and Jai have Turing-complete interpreters in their compilers. OCaml is normally compiled but it also has a nice REPL that people often use in practice (the type inference helps). So there is really no reason to think of interpreters vs. compilers as separate. Both of them should be interactive. Your compiler should be infinitely fast. ----- I probably won't get to this for years, but I can definitely see a path toward making Oil an efficient compiled language. It almost falls naturally out of the odd "bootstrapping" I'm doing.
  - madhadron 7y ago
    > I don't believe in the artificial barriers between interactive and "compiled" languages. Absolutely. Corman Common Lisp was a great example of this. The REPL compiled to efficient x86 machine code.

myrandomcomment 7y ago

So I could read and understand the first example with no issue. At first I was like “yah!” and then as I read on I realized, “yup, your right it is gobbledygook” Then I read this post and said, “chubot you know, you are correct, but I am to old to learn your new fangled —- stuff”. I cannot tell you the number of times I have mistyped - for — and —- for - over the years without thinking about it. Maybe we should make the command expect both and guess based on what’s after. That would make the CLI better.

chubot 7y ago
Yup, Oil will be like Go's flag parser, and accepts one or two dashes! The reason most tools don't is that they allow stuff like rm -rf and tar -xvf, rather than rm -r -f and tar -x -v -f. But that seems to be optimizing for the uncommon case now, given how many tools and flags there are. Nobody can memorize them all!