5 ms·

I wish Unix and co did it the Windows way - leave it to the invoked process to parse. I have an app that takes an SQL query on the command line and I have to re

by billpg 9y ago

I wish Unix and co did it the Windows way - leave it to the invoked process to parse. I have an app that takes an SQL query on the command line and I have to remember I can't just type SELECT * because the shell thinks it knows what I mean by *.

daxelrod 9y ago
Note that even on Windows, you still have to deal with the shell interpreting what you type. The biggest downside of the Windows way, though, is that there stops being one answer to "how do I pass arbitrary strings on the command line to another process"? Sure, most programs use CommandLineToArgvW but it's also hard to find information on how a particular program parses its command line. https://blogs.msdn.microsoft.com/twistylittlepassagesallalike/2011/04/23/everyone-quotes-command-line-arguments-the-wrong-way/ https://blogs.msdn.microsoft.com/twistylittlepassagesallalik... is an overview of the fun that is command line handling on Windows.
- zokier 9y ago
  > Note that even on Windows, you still have to deal with the shell interpreting what you type. Hypothetically that is not strictly true. You could create a shell that would be a very thin wrapper around CreateProcess and not do any interpretation or parsing of the childs arguments. In unixy shell must do at minimum some degree of parsing to split the arguments.
laumars 9y ago
That's your shell rather than the OS. I've been writing my own Linux $SHELL and one of the features is that asterisks don't get expanded by the shell to avoid accidental bugs from the situations you described.
- majewsky 9y ago
  How would you invoke something like `rm * .bak` in such a shell? Do you have a separate command for globbing, such as: rm $(glob *.bak)
  - laumars 9y ago
    Yeah pretty much just that: rm @{g *.bak} `g` returns a JSON array of file names and the @{} tells the shell to expand the array into parameters. This way you don't need to worry about spaces in file names or other problems with escaping.
    - billpg 9y ago
      What if I wanted to delete the two files "@{g" and "*.bak}"?
      - laumars 9y ago
        You'd just put them in quotes as you already had done. In that regard the shell is designed to behave very similarly to Bash.
deleted 9y ago
[deleted]
disconnected 9y ago
I wouldn't change the way bash works because I'm already used to it. After a while, one gets used to it. It's like working in a hazardous environment, full of spinning blades and spikes coming out the wall at random intervals :) But seriously, that's an accident waiting to happen. Like a less knowledgeable user trying to delete a file named * And there are some really awful things you can do by abusing shell expansion. Like this example (WARNING: DON'T BLINDLY RUN THESE!). Go to a directory with non-important files, and do: touch ./-f touch ./-r rm * Since there's a good chance that all of your files have sensible names (that is, they don't start with weird symbols), that will expand to: rm -f -r [the rest of your files] Oops. Kiss your files AND directories goodbye. That includes write protected files that would give rise to a warning if you tried to remove them. And in a cruel ironic twist, the files named '-r' and '-f' are preserved. But the problem is actually made worse by the fact that most command line parsing libraries allow flags to be condensed into a single option (like -r -f can be condensed into -rf). GNU utilities do this by default. This coupled with expanding * turns ANY file that starts with a leading - into a potential source of doom. So, imagine that you have a file named '-truffle' in there somewhere. rm * expands to 'rm -truffle [your files]'. That is interpreted by rm as "rm -t -r -u -f -f -l -e [your files]" (note the presence of '-r' and '-f'). Gasp and horror! However, your salvation is that rm halts if it encounters an unknown option (like -u). You can wipe your brow and sigh in relief, because you just dodged a bullet. IIRC, the Unix haters handbook dedicates a whole chapter to these types of landmines, and the "funny" thing is that most of it still applies, about two decades after it was written.

by billpg 9y ago

daxelrod 9y ago

Note that even on Windows, you still have to deal with the shell interpreting what you type. The biggest downside of the Windows way, though, is that there stops being one answer to "how do I pass arbitrary strings on the command line to another process"? Sure, most programs use CommandLineToArgvW but it's also hard to find information on how a particular program parses its command line. https://blogs.msdn.microsoft.com/twistylittlepassagesallalike/2011/04/23/everyone-quotes-command-line-arguments-the-wrong-way/ https://blogs.msdn.microsoft.com/twistylittlepassagesallalik... is an overview of the fun that is command line handling on Windows.

zokier 9y ago
> Note that even on Windows, you still have to deal with the shell interpreting what you type. Hypothetically that is not strictly true. You could create a shell that would be a very thin wrapper around CreateProcess and not do any interpretation or parsing of the childs arguments. In unixy shell must do at minimum some degree of parsing to split the arguments.

laumars 9y ago

That's your shell rather than the OS. I've been writing my own Linux $SHELL and one of the features is that asterisks don't get expanded by the shell to avoid accidental bugs from the situations you described.

majewsky 9y ago
How would you invoke something like `rm * .bak` in such a shell? Do you have a separate command for globbing, such as: rm $(glob *.bak)
- laumars 9y ago
  Yeah pretty much just that: rm @{g *.bak} `g` returns a JSON array of file names and the @{} tells the shell to expand the array into parameters. This way you don't need to worry about spaces in file names or other problems with escaping.
  - billpg 9y ago
    What if I wanted to delete the two files "@{g" and "*.bak}"?
    - laumars 9y ago
      You'd just put them in quotes as you already had done. In that regard the shell is designed to behave very similarly to Bash.

deleted 9y ago

[deleted]

disconnected 9y ago

I wouldn't change the way bash works because I'm already used to it. After a while, one gets used to it. It's like working in a hazardous environment, full of spinning blades and spikes coming out the wall at random intervals :) But seriously, that's an accident waiting to happen. Like a less knowledgeable user trying to delete a file named * And there are some really awful things you can do by abusing shell expansion. Like this example (WARNING: DON'T BLINDLY RUN THESE!). Go to a directory with non-important files, and do: touch ./-f touch ./-r rm * Since there's a good chance that all of your files have sensible names (that is, they don't start with weird symbols), that will expand to: rm -f -r [the rest of your files] Oops. Kiss your files AND directories goodbye. That includes write protected files that would give rise to a warning if you tried to remove them. And in a cruel ironic twist, the files named '-r' and '-f' are preserved. But the problem is actually made worse by the fact that most command line parsing libraries allow flags to be condensed into a single option (like -r -f can be condensed into -rf). GNU utilities do this by default. This coupled with expanding * turns ANY file that starts with a leading - into a potential source of doom. So, imagine that you have a file named '-truffle' in there somewhere. rm * expands to 'rm -truffle [your files]'. That is interpreted by rm as "rm -t -r -u -f -f -l -e [your files]" (note the presence of '-r' and '-f'). Gasp and horror! However, your salvation is that rm halts if it encounters an unknown option (like -u). You can wipe your brow and sigh in relief, because you just dodged a bullet. IIRC, the Unix haters handbook dedicates a whole chapter to these types of landmines, and the "funny" thing is that most of it still applies, about two decades after it was written.