5 ms·

Not to mention how dangerous it is to use. Accidentally type the > symbol? Enjoy overwriting whichever file came after in the command. Output to an existing fil

Not to mention how dangerous it is to use. Accidentally type the > symbol? Enjoy overwriting whichever file came after in the command. Output to an existing file? Old file is gone. Accidentally put a space the wrong place? Gone. And somehow people think mastering this careless design is something to be proud of. Can anyone name any other popular piece of software that is that relaxed about irreversibly destroying your data?

hpoe 5y ago
Well "mastering [that] careless design" has made me farore capable than many of my peers at tasks that involve debugging network problems. I can slice and dice data files with ease and much more speed than any of my associates because the power the shell brings, I have gained a much deeper understanding of how am OS and computing works, what is going on under the hood, and consequently have reaped many advantages due to many hours spent mastering the shell. You are right it has some warts, but if a file is really that absolutely critical I make a .bak copy of it before I start my work. The shell has its limitations but so do all tools and the power it gives me is unmatched. As for other popular software there is plenty out there but other popular software out there destroys something far more valuable to me. My time.
- dTal 5y ago
  >You are right it has some warts, but if a file is really that absolutely critical I make a .bak copy of it before I start my work This seems to miss the point completely, unless you back up your entire hard disk before running every command. The whole problem is it's easy to nuke things you weren't intending to touch, accidentally. The user-hostility of the shell is not a required feature to achieve its power. All of the advantages you cite could be had without being a terrible footgun with human factors mired in 1970s computing culture.
  - z3ncyberpunk 5y ago
    you do realize Linux has file permissions which can prevent accidental deletion...
- unrealhoang 5y ago
  How is any of the advantages you listed not achievable by learning a better programming language, say, Python?
  - NegativeLatency 5y ago
    Some of them are but for quick stuff it’s hard to match the speed and flexibility of the shell
hnlmorg 5y ago
Pretty much every RDBMS on the planet (and some no-SQL databases too). :) I jest but I do agree that Bash et al have their warts. Seriously obscene warts that only make sense when you look at the language from the content of 40 year old systems. But these days there are other options if you want the power of a command line but without (most of) the warts of traditional shells.
citrin_ru 5y ago
Lack of warnings about accidental file overwrite is less of a problem today than say 20-30 years ago: modern filesystems allows to make regular snapshots which help to recover accidentally lost file. It doesn't happen often in my practice, but by doing what told without questions shell saves my time every day.
zvr 5y ago
If you are that concerned about this specific problem, shell allows you to "set noclobber" (or "set -C") to not overwrite existing files.
- chubot 5y ago
  Yup, I only learned about that while writing https://www.oilshell.org https://www.oilshell.org ! I'm sure that has been around for decades; shell also has discovery and documentation problems :)
  - wahern 5y ago
    > shell also has discovery and documentation problems Only because people refuse to read the specification. The POSIX Shell & Utilities volume is exceedingly clear and straight-forward. (I vehemently disagree w/ its characterization in that paper.) It helps if you use the frames-based HTML version to make it easier to navigate and explore the various utilities, and especially to see how the syntax specification is broken down--while that section is short, it's difficult to appreciate without explicitly seeing how the subsections are related. I only code in POSIX shell because I really can't be bothered to remember all the minutiae of other shells, almost all of which provide strong POSIX compatibility, Bash especially. I've never lamented the lack of arrays; but I regularly wish that POSIX would adopt ksh-style coprocesses so dash would have them. The shell is really all about stitching together processes (including subshell contexts), and coprocesses fill a conspicuous gap in functionality.
    - chubot 5y ago
      I've never used ksh-style coprocesses so I'd be interested to hear about some use cases for them, and what you like about them. Examples would be even better -- I've never seen them, and I've looked at a lot of shell. Bash has a different implementation of coprocesses that doesn't seem to be used much, and is very limited. I believe there can only be one coprocess active at a time, which is very un-shell-like! I got an e-mail once from someone who was using them, and I felt it could be achieved by other means. I have a good idea coprocesses in Oil which basically is a startup time optimization. The coprocess will basically take argv over a unix domain socket, and have other commands to change the process state. It solves "the problem of VMs and containers that start slowly". https://www.oilshell.org/blog/2021/04/release-0.8.9.html#whats-next https://www.oilshell.org/blog/2021/04/release-0.8.9.html#wha... Unix domain sockets are already used for the headless shell in Oil (more coming on the blog about that) https://www.oilshell.org/release/latest/doc/headless.html#implement-the-fanos-protocol https://www.oilshell.org/release/latest/doc/headless.html#im...
pmoriarty 5y ago
"Not to mention how dangerous it is to use. Accidentally type the > symbol? Enjoy overwriting whichever file came after in the command." At least in zsh, you can prevent such mistakes by setopt NO_CLOBBER It's saved my bacon many times. Also, from bitter experience I've forced myself to get in to the habit of never typing: rm * but instead always doing: cd .. rm foo/* It forces me to be more conscious of what I'm deleting.
- teddyh 5y ago
  > in zsh […] setopt NO_CLOBBER In Bash it’s set -o noclobber or set -C
  - gnubison 5y ago
    Those work in any POSIX shell, and also zsh.
    - teddyh 5y ago
      It seems you are correct: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#set https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V...
- bccdee 5y ago
  I have `alias rm="echo DISABLED"` in my shell rc, and I have `trash` defined as a big shell function that safely moves stuff to the x desktop trash bin without clobbering anything. It's mildly irritating, but it gives me incredible peace of mind.
farisjarrah 5y ago
A circular saw can easily ruin a piece of work if your not careful, and it could even chop off your hand. We don't tell carpenters that they shouldn't use saws because they are dangerous. There are lots of jobs that are work with dangerous tools.
- jakobnissen 5y ago
  If a manufacturer could easily design the circular saw to be safe (á la SawStop) with little added cost, but decided not to, I think most people would consider them grossly negligent.
  - PoignardAzur 5y ago
    Huh. I didn't know about SawStop before, so your comment sent me on a wiki-hunt. "Gross negligence" seems like a huge understatement for all the rationalizing and lobbying manufacturers did to avoid having to use safety technology. https://en.wikipedia.org/wiki/SawStop#Opposition_from_trade_group_(2008) https://en.wikipedia.org/wiki/SawStop#Opposition_from_trade_...
- oblio 5y ago
  A saw is <<hard>>ware, a physical thinghard to change and improve, while a shell is <<soft>>ware, supposed to be easy to change and improve.

hpoe 5y ago

Well "mastering [that] careless design" has made me farore capable than many of my peers at tasks that involve debugging network problems. I can slice and dice data files with ease and much more speed than any of my associates because the power the shell brings, I have gained a much deeper understanding of how am OS and computing works, what is going on under the hood, and consequently have reaped many advantages due to many hours spent mastering the shell. You are right it has some warts, but if a file is really that absolutely critical I make a .bak copy of it before I start my work. The shell has its limitations but so do all tools and the power it gives me is unmatched. As for other popular software there is plenty out there but other popular software out there destroys something far more valuable to me. My time.

dTal 5y ago
>You are right it has some warts, but if a file is really that absolutely critical I make a .bak copy of it before I start my work This seems to miss the point completely, unless you back up your entire hard disk before running every command. The whole problem is it's easy to nuke things you weren't intending to touch, accidentally. The user-hostility of the shell is not a required feature to achieve its power. All of the advantages you cite could be had without being a terrible footgun with human factors mired in 1970s computing culture.
- z3ncyberpunk 5y ago
  you do realize Linux has file permissions which can prevent accidental deletion...
unrealhoang 5y ago
How is any of the advantages you listed not achievable by learning a better programming language, say, Python?
- NegativeLatency 5y ago
  Some of them are but for quick stuff it’s hard to match the speed and flexibility of the shell

hnlmorg 5y ago

Pretty much every RDBMS on the planet (and some no-SQL databases too). :) I jest but I do agree that Bash et al have their warts. Seriously obscene warts that only make sense when you look at the language from the content of 40 year old systems. But these days there are other options if you want the power of a command line but without (most of) the warts of traditional shells.

citrin_ru 5y ago

Lack of warnings about accidental file overwrite is less of a problem today than say 20-30 years ago: modern filesystems allows to make regular snapshots which help to recover accidentally lost file. It doesn't happen often in my practice, but by doing what told without questions shell saves my time every day.

zvr 5y ago

If you are that concerned about this specific problem, shell allows you to "set noclobber" (or "set -C") to not overwrite existing files.

chubot 5y ago
Yup, I only learned about that while writing https://www.oilshell.org https://www.oilshell.org ! I'm sure that has been around for decades; shell also has discovery and documentation problems :)
- wahern 5y ago
  > shell also has discovery and documentation problems Only because people refuse to read the specification. The POSIX Shell & Utilities volume is exceedingly clear and straight-forward. (I vehemently disagree w/ its characterization in that paper.) It helps if you use the frames-based HTML version to make it easier to navigate and explore the various utilities, and especially to see how the syntax specification is broken down--while that section is short, it's difficult to appreciate without explicitly seeing how the subsections are related. I only code in POSIX shell because I really can't be bothered to remember all the minutiae of other shells, almost all of which provide strong POSIX compatibility, Bash especially. I've never lamented the lack of arrays; but I regularly wish that POSIX would adopt ksh-style coprocesses so dash would have them. The shell is really all about stitching together processes (including subshell contexts), and coprocesses fill a conspicuous gap in functionality.
  - chubot 5y ago
    I've never used ksh-style coprocesses so I'd be interested to hear about some use cases for them, and what you like about them. Examples would be even better -- I've never seen them, and I've looked at a lot of shell. Bash has a different implementation of coprocesses that doesn't seem to be used much, and is very limited. I believe there can only be one coprocess active at a time, which is very un-shell-like! I got an e-mail once from someone who was using them, and I felt it could be achieved by other means. I have a good idea coprocesses in Oil which basically is a startup time optimization. The coprocess will basically take argv over a unix domain socket, and have other commands to change the process state. It solves "the problem of VMs and containers that start slowly". https://www.oilshell.org/blog/2021/04/release-0.8.9.html#whats-next https://www.oilshell.org/blog/2021/04/release-0.8.9.html#wha... Unix domain sockets are already used for the headless shell in Oil (more coming on the blog about that) https://www.oilshell.org/release/latest/doc/headless.html#implement-the-fanos-protocol https://www.oilshell.org/release/latest/doc/headless.html#im...

pmoriarty 5y ago

"Not to mention how dangerous it is to use. Accidentally type the > symbol? Enjoy overwriting whichever file came after in the command." At least in zsh, you can prevent such mistakes by setopt NO_CLOBBER It's saved my bacon many times. Also, from bitter experience I've forced myself to get in to the habit of never typing: rm * but instead always doing: cd .. rm foo/* It forces me to be more conscious of what I'm deleting.

teddyh 5y ago
> in zsh […] setopt NO_CLOBBER In Bash it’s set -o noclobber or set -C
- gnubison 5y ago
  Those work in any POSIX shell, and also zsh.
  - teddyh 5y ago
    It seems you are correct: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#set https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V...
bccdee 5y ago
I have `alias rm="echo DISABLED"` in my shell rc, and I have `trash` defined as a big shell function that safely moves stuff to the x desktop trash bin without clobbering anything. It's mildly irritating, but it gives me incredible peace of mind.

farisjarrah 5y ago

A circular saw can easily ruin a piece of work if your not careful, and it could even chop off your hand. We don't tell carpenters that they shouldn't use saws because they are dangerous. There are lots of jobs that are work with dangerous tools.

jakobnissen 5y ago
If a manufacturer could easily design the circular saw to be safe (á la SawStop) with little added cost, but decided not to, I think most people would consider them grossly negligent.
- PoignardAzur 5y ago
  Huh. I didn't know about SawStop before, so your comment sent me on a wiki-hunt. "Gross negligence" seems like a huge understatement for all the rationalizing and lobbying manufacturers did to avoid having to use safety technology. https://en.wikipedia.org/wiki/SawStop#Opposition_from_trade_group_(2008) https://en.wikipedia.org/wiki/SawStop#Opposition_from_trade_...
oblio 5y ago
A saw is <<hard>>ware, a physical thinghard to change and improve, while a shell is <<soft>>ware, supposed to be easy to change and improve.