4 ms·

This is a UI/UX problem that I only face when dealing with shells and shell scripts. Never had any issues when spawning processes from within languages/runtimes

by sieve 5y ago

This is a UI/UX problem that I only face when dealing with shells and shell scripts. Never had any issues when spawning processes from within languages/runtimes that support sane argument arrays. sh, bash and cmd.exe are shit. The shell needs serious rethinking.

Joker_vD 5y ago
I see that there are lots of comments about problems of TAB-completions with filenames with spaces in this comment section and I am frankly puzzled: both Bash and cmd.exe actually TAB-complete those perfectly fine, inserting quoting where it's needed.
- necovek 5y ago
  I seem to remember bash losing preferred escaping when TAB-completing, but can't reproduce it now with 5.0.17. Eg. you'd type `ls -l "Spaced [TAB]` and it would turn it into `ls -l Spaced\ Name`. I remember similar annoyances with other special shell characters (eg. single quotes, dollars, slashes), but that all seems to behave sane now.
  - xyzzy_plugh 5y ago
    I didn't even know this was a thing, but can't say I've ever preferred an escape style. I actually use backslashes a fair bit, usually just with spaces. I tend to reserve double quotes for variable or shell expansion, explicitly.
    - necovek 5y ago
      It's not so much about a preference, but your cursor would jump about and you'd need to be on the lookout if you wanted to edit the completion (eg. to change the extension).
- sieve 5y ago
  > inserting quoting where it's needed You have to remind yourself to do this manually in scripts if you don't want to see lines full of "No such file or directory." One of the reasons the shell is broken is because the character they use as an argument array member separator is something that regular people use to distinguish between two words, such as in a file name.
  - Joker_vD 5y ago
    Well, writing scripts would be much less painful if $VARNAME did not explode into pieces by default. Alas, this ship has sailed long ago.
    - goohle 5y ago
      IMHO, it's possible to add a flag to bash, which will turn on this behavior, so problem can be fixed, but it will diverge bash from POSIX sh a lot.
- tremon 5y ago
  And where it isn't needed. If you have a path that contains a variable and a space, bash will happily escape the $, making the path invalid. See the following: $ cd $HOME $ mkdir my\ dir $ ls my[tab] $ cd / $ ls $HOME/my[tab] ls: cannot access '$HOME/my dir/': No such file or directory That error is because when you press [tab], bash changed the path to \$HOME/my\ dir/ but that isn't obvious from the output and I couldn't find a proper way to include the tab-expanded result in the transcript. (edit: this is on GNU bash, version 4.3.48(1)-release but I've seen this behaviour for years)
  - Joker_vD 5y ago
    Depends on the Bash version, I guess? Mine is 4.4.20(1) and when I do "cd $HOME/my[TAB]", it replaces the input line with "cd /home/joker/my\ dir/", and pressing [ENTER] changes the directory to '/home/joker/my dir', as can be seen from the prompt.
    - akovaski 5y ago
      The variable escaping behavior has existed for a while https://stackoverflow.com/questions/32463052/bash-tabbing-for-autocompletion-escapes https://stackoverflow.com/questions/32463052/bash-tabbing-fo... https://askubuntu.com/questions/70750/how-to-get-bash-to-stop-escaping-during-tab-completion https://askubuntu.com/questions/70750/how-to-get-bash-to-sto... https://askubuntu.com/questions/41891/bash-auto-complete-for-environment-variables https://askubuntu.com/questions/41891/bash-auto-complete-for... And I experience the problematic behavior on my Ubuntu VM. However, I can get the above describe expansion behavior if I run: shopt -s direxpand
necovek 5y ago
This is a difference between $@ and "$@" (note the quotes): $ cat proba.sh #!/bin/sh echo "Using quotes:" for i in "$@"; do echo "$i"; done echo "No quotes:" for i in $@; do echo "$i"; done $ ./proba.sh "ho ho ho" Using quotes: ho ho ho No quotes: ho ho ho
- tomcam 5y ago
  Damn I didn’t know that. Thanks

by sieve 5y ago

Joker_vD 5y ago

I see that there are lots of comments about problems of TAB-completions with filenames with spaces in this comment section and I am frankly puzzled: both Bash and cmd.exe actually TAB-complete those perfectly fine, inserting quoting where it's needed.

necovek 5y ago
I seem to remember bash losing preferred escaping when TAB-completing, but can't reproduce it now with 5.0.17. Eg. you'd type `ls -l "Spaced [TAB]` and it would turn it into `ls -l Spaced\ Name`. I remember similar annoyances with other special shell characters (eg. single quotes, dollars, slashes), but that all seems to behave sane now.
- xyzzy_plugh 5y ago
  I didn't even know this was a thing, but can't say I've ever preferred an escape style. I actually use backslashes a fair bit, usually just with spaces. I tend to reserve double quotes for variable or shell expansion, explicitly.
  - necovek 5y ago
    It's not so much about a preference, but your cursor would jump about and you'd need to be on the lookout if you wanted to edit the completion (eg. to change the extension).
sieve 5y ago
> inserting quoting where it's needed You have to remind yourself to do this manually in scripts if you don't want to see lines full of "No such file or directory." One of the reasons the shell is broken is because the character they use as an argument array member separator is something that regular people use to distinguish between two words, such as in a file name.
- Joker_vD 5y ago
  Well, writing scripts would be much less painful if $VARNAME did not explode into pieces by default. Alas, this ship has sailed long ago.
  - goohle 5y ago
    IMHO, it's possible to add a flag to bash, which will turn on this behavior, so problem can be fixed, but it will diverge bash from POSIX sh a lot.
tremon 5y ago
And where it isn't needed. If you have a path that contains a variable and a space, bash will happily escape the $, making the path invalid. See the following: $ cd $HOME $ mkdir my\ dir $ ls my[tab] $ cd / $ ls $HOME/my[tab] ls: cannot access '$HOME/my dir/': No such file or directory That error is because when you press [tab], bash changed the path to \$HOME/my\ dir/ but that isn't obvious from the output and I couldn't find a proper way to include the tab-expanded result in the transcript. (edit: this is on GNU bash, version 4.3.48(1)-release but I've seen this behaviour for years)
- Joker_vD 5y ago
  Depends on the Bash version, I guess? Mine is 4.4.20(1) and when I do "cd $HOME/my[TAB]", it replaces the input line with "cd /home/joker/my\ dir/", and pressing [ENTER] changes the directory to '/home/joker/my dir', as can be seen from the prompt.
  - akovaski 5y ago
    The variable escaping behavior has existed for a while https://stackoverflow.com/questions/32463052/bash-tabbing-for-autocompletion-escapes https://stackoverflow.com/questions/32463052/bash-tabbing-fo... https://askubuntu.com/questions/70750/how-to-get-bash-to-stop-escaping-during-tab-completion https://askubuntu.com/questions/70750/how-to-get-bash-to-sto... https://askubuntu.com/questions/41891/bash-auto-complete-for-environment-variables https://askubuntu.com/questions/41891/bash-auto-complete-for... And I experience the problematic behavior on my Ubuntu VM. However, I can get the above describe expansion behavior if I run: shopt -s direxpand

necovek 5y ago

This is a difference between $@ and "$@" (note the quotes): $ cat proba.sh #!/bin/sh echo "Using quotes:" for i in "$@"; do echo "$i"; done echo "No quotes:" for i in $@; do echo "$i"; done $ ./proba.sh "ho ho ho" Using quotes: ho ho ho No quotes: ho ho ho

tomcam 5y ago
Damn I didn’t know that. Thanks