3 ms·

It's interesting, that no one questioned the use of double dash itself. It looks especially silly, when long options are used to encode some mini programming l

by onetom 4y ago

It's interesting, that no one questioned the use of double dash itself. It looks especially silly, when long options are used to encode some mini programming language (DSL), like in imagemagick and ffmpeg, or when they are used to represent some associative data, like in case of the AWS CLI. If -- would be a : AFTER the option name, it would look like Objective C named arguments or set-words in REBOL and Red. If -- would be a : BEFORE the option name, it would look like keywords in Lisps. As a side-note, shells got quite evolved, actually, but the momentum of the mediocre bash-line prevailed, sadly. I urge people to learn about es, the Extensible Shell: https://wryun.github.io/es-shell/ https://wryun.github.io/es-shell/ Its ancestor, the Plan 9 rc (which I think stands for Run Command) and it used "; " as a prompt, so u could combine multiple commands easier, by copy-pasting whole lines, instead of fiddling with the exclusion of the varying length prompt. Both of these shells have a lot better string quoting rules than bash, so they play nicer with filenames containing special characters. They also follow the unix philosophy closer, by not necessarily providing line editing capabilities, which can be added by running them thru eg. rlwrap or not really needed, when running them from Emacs or Plan 9's acme environment. I would also highlight, that es is just 163KB, while bash is 1.3MB, yet it provides a magnitudes more powerful, dynamic, garbage collected, functional programming language!

theamk 4y ago
The double-dash is selected for pure practicality. Any option character excludes a set of inputs, and we want this set to be as small as possible. It is already hard to look at file named "-f" -- do you want to also make accessing files named ":f" (or even worse, "f:") harder? Thus the desire to keep the first "-". Now, they could have used "-:" or "-=" for long options.. but I think "--" won because it is so easy to type -- no need to move your fingers. Using long options to encode DSL, like imagemagick and ffmpeg, can be pretty silly.. But those programs are exceptions, and most of the option usage is of much simpler variety. Like "grep --label=input --color=always". The comments about es sound weird... You can set ";" as prompt in sh/bash too. I would not call its quoting "nicer" -- yes, using '' for a single quote is nice, but lack of " support sounds like a bad omission. Yes, bash is pretty fat by 1990's standards.. but if you want a real programming language with no line editing capabilities, no need to reach for obscure shells -- grab perl, python, tcl, lua or any of the other scripting languages.
- onetom 4y ago
  I understand, that the double-dash was a logical step from a single-dash. My problem is, what we ended up with, is really not great. It's a typical case of the slowly boiled frog... rc and es is an good example of what improvements can be achieved, if we challenge historical decisions and get rid of the not so great ones. The "; " prompt was just a historical side-note, because I saw someone asking about it the other day on twitter: https://twitter.com/thingskatedid/status/1316081075043463170?s=20&t=qrIP_XbAikNdNrFgKDJ5eQ https://twitter.com/thingskatedid/status/1316081075043463170... By the quoting rules, I meant, that if you have a variable (eg v='a b') with a value containing whitespace, when you reference it ($v), then you don't have to worry about quoting it in any way, because the space in its value won't cause any problems.
- onetom 4y ago
  btw, Rebol solved the mixing of options and filenames by introducing a syntax for file references; u prefix them with a percent sign, eg.: %/c/plug-in/video.r %//sound/goldfinger.mp3 %"/c/program files/qualcomm/eudora mail/out.mbx" %c:/docs/file.txt %\some\cool\movie.mpg <= understood backslashes too, so it worked in DOS/Windows too! %cool%20movie%20clip.mpg Source: http://www.rebol.com/docs/core23/rebolcore-12.html#section-2.1 http://www.rebol.com/docs/core23/rebolcore-12.html#section-2... then you could mix them with `:get-words` and `set-words:`. Rebol also had an interesting take on options - with and without arguments -; it called them refinements and you would just stack them with slashes onto the "command". the refinement arguments were added to the end of the parameter list though, so it was not exactly obvious which argument belonged to which refinement, but in practice it worked quite nice, surprisingly: str: "test" insert/dup/part str "this one" 4 5 print str => this this this this test and reversing /dup and /part: str: "test" insert/part/dup str "this one" 4 5 print str => thisthisthisthisthistest Source: http://www.rebol.com/docs/core23/rebolcore-9.html#section-2.3 http://www.rebol.com/docs/core23/rebolcore-9.html#section-2....

by onetom 4y ago

theamk 4y ago

The double-dash is selected for pure practicality. Any option character excludes a set of inputs, and we want this set to be as small as possible. It is already hard to look at file named "-f" -- do you want to also make accessing files named ":f" (or even worse, "f:") harder? Thus the desire to keep the first "-". Now, they could have used "-:" or "-=" for long options.. but I think "--" won because it is so easy to type -- no need to move your fingers. Using long options to encode DSL, like imagemagick and ffmpeg, can be pretty silly.. But those programs are exceptions, and most of the option usage is of much simpler variety. Like "grep --label=input --color=always". The comments about es sound weird... You can set ";" as prompt in sh/bash too. I would not call its quoting "nicer" -- yes, using '' for a single quote is nice, but lack of " support sounds like a bad omission. Yes, bash is pretty fat by 1990's standards.. but if you want a real programming language with no line editing capabilities, no need to reach for obscure shells -- grab perl, python, tcl, lua or any of the other scripting languages.

onetom 4y ago
I understand, that the double-dash was a logical step from a single-dash. My problem is, what we ended up with, is really not great. It's a typical case of the slowly boiled frog... rc and es is an good example of what improvements can be achieved, if we challenge historical decisions and get rid of the not so great ones. The "; " prompt was just a historical side-note, because I saw someone asking about it the other day on twitter: https://twitter.com/thingskatedid/status/1316081075043463170?s=20&t=qrIP_XbAikNdNrFgKDJ5eQ https://twitter.com/thingskatedid/status/1316081075043463170... By the quoting rules, I meant, that if you have a variable (eg v='a b') with a value containing whitespace, when you reference it ($v), then you don't have to worry about quoting it in any way, because the space in its value won't cause any problems.
onetom 4y ago
btw, Rebol solved the mixing of options and filenames by introducing a syntax for file references; u prefix them with a percent sign, eg.: %/c/plug-in/video.r %//sound/goldfinger.mp3 %"/c/program files/qualcomm/eudora mail/out.mbx" %c:/docs/file.txt %\some\cool\movie.mpg <= understood backslashes too, so it worked in DOS/Windows too! %cool%20movie%20clip.mpg Source: http://www.rebol.com/docs/core23/rebolcore-12.html#section-2.1 http://www.rebol.com/docs/core23/rebolcore-12.html#section-2... then you could mix them with `:get-words` and `set-words:`. Rebol also had an interesting take on options - with and without arguments -; it called them refinements and you would just stack them with slashes onto the "command". the refinement arguments were added to the end of the parameter list though, so it was not exactly obvious which argument belonged to which refinement, but in practice it worked quite nice, surprisingly: str: "test" insert/dup/part str "this one" 4 5 print str => this this this this test and reversing /dup and /part: str: "test" insert/part/dup str "this one" 4 5 print str => thisthisthisthisthistest Source: http://www.rebol.com/docs/core23/rebolcore-9.html#section-2.3 http://www.rebol.com/docs/core23/rebolcore-9.html#section-2....