Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bash Pitfalls

bash.cumulonim.biz

Post reply on HN
Print view View original

21–30 of 55 posts

Re: Bash Pitfalls

#21

Post by clarry »

Sivart13 wrote: post #5
mlacitation wrote: post #2

I have a mirror of this site. wooledge.org runs off of greycat's (#bash on freenode) home DSL connection: http://bash.cumulonim.biz/BashPitfalls.html

Seriously? They can't find a better place to host a site like this here in 2013?

If you already have a machine serving stuff at home, adding a remote server is only time, money, and effort spent. Is it worth it? Not all sites are high in volume, and even well prepared sites on decent lines can go down if it hits the HN front page.

People do occasionally bitch and moan about slow downloads from my home host, but nobody ever offered money for a pain-free alternative.

Re: Bash Pitfalls

#23

Post by brandonbloom »

clarry wrote: post #15
druiid wrote: post #13

Earlier quoted context omitted.

I totally agree. Sometimes the strength of making a 'quick bash script', is that you are making a quick bash script. I have made some pretty strong, well tested projects in bash before including one that was a big part of an open-source qmail project. Sometimes though you just need to get stuff done with the least amount of fuss, without worrying about the extreme edge-cases which the majority of the webpage attached…

On the other hand, if you examine the given examples, you'll see that very often the "correct" way isn't really longer or harder to type. If you make a point of sticking to the correct way, it will eventually become automatic, and there'll be no fuss and worry. This might end up saving some sorry ass later on. And having learned the correct way, you'll instantly see it when a script you review is doing something in a…

> There's no downsides to learning and doing things right.

There is never "no downsides".

For one example, there is "feedback fatigue". It's easy to pick on syntax or "small" semantics during a code review, but that's not nearly as useful as analyzing the big picture. I have been party to many code reviews that involved a dozen nit-picky stylistic comments. The reviewer feels like they did their job, the reviewee feels like they have appeased the reviewer, and so the now style-guide-correct code gets a half-hearted "LGTM" and is merged. That code looks great... And it handles filenames with spaces in them!.. But does the totally wrong thing.

Re: Bash Pitfalls

#24

Post by thristian »

comex wrote: post #7

The Unix shell may be a highly powerful interactive programming environment, but it's sure hard to think of anything that comes anywhere close to sucking as badly. With the shell and the standard Unix commands, some things that are hard in other languages are easy, and most of the things that are easy in other languages are hard to impossible... I'd love to see a clean slate replacement for the shell that still feels…

Have you looked at "rc", the shell from Plan 9? It's very similar in spirit to the Bourne shell, but it's fundamentally better thought-out.

http://plan9.bell-labs.com/sys/doc/rc.html

Re: Bash Pitfalls

#25

Post by PhasmaFelis »

So why do we put up with classic command line tools in general that are so full of horrible, counterintuitive pitfalls? Is it just tradition? Backwards compatibility?

The "Unix should be hard" crew has gotten a lot quieter in the last ten years with the rise of Ubuntu and other relatively user-friendly distros, but I feel like there's still an underlying current of elitism there; people are proud of mastering these bizarre, arcane methods, and they're offended that someone else might be able to accomplish just as much without doing half as much work.

Re: Bash Pitfalls

#26

Post by brennen »

brandonbloom wrote: post #12

Maybe some controversial advice: Go ahead, fall in these pits. I write my fair share of shell scripts and I've hit practically every one of these snags in the past. However, for the majority of tasks I perform with bash, I genuinely don't care if I support spaces in filenames, or if I throw away a little efficiency with a few extra sub-shells, or if I can't test numbers vs strings or have a weird notion of booleans.…

I live and die by the shell. I'm constantly composing little one-liners, and keep an absurdly long Bash / zsh history to draw from. There are places the obvious answer is almost always "how about you just write a shell script?"

That said, I long ago reached a place where I realized that, while shell scripting is entertaining, I'd much rather write anything more than a handful of lines in a general purpose programming language. Perl, Python, Ruby, whatever - even PHP involves far less syntactic suffering and general impedance than Bash. It's not that I'm exceptionally worried about correctness in stuff that no one besides me is ever going to use, it's just that once you're past a certain very low threshold of complexity, the agony you spend for a piece of reusable code is so much less. Even just stitching together some standard utilities, there are plenty of times it'll take a tenth as long and a thousandth as much swearing to just write some Perl that uses backticks here and there or mangles STDIN as needed.

  > Are your scripts idempotent? Are they
  > audit-able? Interruptible? Do you have
  > backups before performing destructive
  > operations? How do you verify that they
  > did the right job?
Every single one of these questions is easier to answer if you're using a less agonizing language than Bash and its relatives.

Re: Bash Pitfalls

#28

Post by joseph »

sigil wrote: post #20
Aardwolf wrote: post #16

The following does not work on files with spaces according to the article: for i in $(ls *.mp3); do some command $i done So does that mean, that "for" will do something per word of the output of $, rather than per line of output of it? What to do if I want to do something for every line? What for example if I really want the output of ls, find (or any other command you can put int he $()) and loop through that line p…

> So does that mean, that "for" will do something per word of the output of $, rather than per line of output of it? Correct. The argument to "for" is a list of words. > What to do if I want to do something for every line? Use a while loop. find /some/dir/ -type f | while read -r line; do ; # something with $line done PS. You should almost always use `find` instead of `ls` in shell scripts. Given a pattern, `ls` will…

One thing to be careful of when doing "while read..." is that a new shell is started on each iteration, so you cannot for example set a variable within the loop that you can use later in the script, as its value will be lost when the shell process exits.

Re: Bash Pitfalls

#29

Post by mixmastamyk »

PhasmaFelis wrote: post #25

So why do we put up with classic command line tools in general that are so full of horrible, counterintuitive pitfalls? Is it just tradition? Backwards compatibility? The "Unix should be hard" crew has gotten a lot quieter in the last ten years with the rise of Ubuntu and other relatively user-friendly distros, but I feel like there's still an underlying current of elitism there; people are proud of mastering these b…

There are alternatives. I use the fish shell for interactive work, and python when a bash script surpasses a certain complexity.

Re: Bash Pitfalls

#30

Post by mixmastamyk »

comex wrote: post #7

The Unix shell may be a highly powerful interactive programming environment, but it's sure hard to think of anything that comes anywhere close to sucking as badly. With the shell and the standard Unix commands, some things that are hard in other languages are easy, and most of the things that are easy in other languages are hard to impossible... I'd love to see a clean slate replacement for the shell that still feels…

Hmm, sounds like you've never written batch files, the ultimate in "suck", but then you mention PowerShell, so I'm not so sure.

Anyway, I enjoy using the fish shell, and you may too.

Post reply on HN