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

Bash Pitfalls

mywiki.wooledge.org

Post reply on HN
Print view View original

31–35 of 35 posts

Re: Bash Pitfalls

#31

Post by psd1 »

Aloha wrote: post #22
skrtskrt wrote: post #20

Earlier quoted context omitted.

there's just no way we should all be scripting in a language where typing out anything more than a single command necessitates a cascade of "well ACKshually it should be done this way" corrections, whether it's from a static analysis tools or your grey-bearded Bash-wizard coworkers. We are eventually going to look at using bash and similar shells for scripting as the bad old days.

If there is only one correct answer to a problem in a given language, people will shunt that creativity to architecture or elsewhere. People still want to be creative in their work, programming and system administration is fundamentally a creative job. Which would you rather have, a script that was too clever by half, or a system architecture that was too clever by half? It's a whole lot easier to fix the script than…

...technical debt as a safety valve against surplus engineering talent!

Re: Bash Pitfalls

#32

Post by HenrikB »

actually_a_dog wrote: post #21
HenrikB wrote: post #19

(Disclaimer: I'm the co-developer) Together with GitHub user xPMo, I created a Shellcheck REPL tool ( https://github.com/HenrikBengtsson/shellcheck-repl ) that validates your Bash commands using ShellCheck _before_ they are evaluated. For example, $ words="lorem ipsum dolor" $ echo $words ^-- SC2086: Double quote to prevent globbing and word splitting. It was a toy project at first, but since I've learned so much abo…

Neat. I like it. I do have one suggestion: you have it ignoring "SC2154: 'var' is referenced but not assigned" by default, which makes sense on the command line because you're often not assigning and then referencing the same variable in a single command. But, I think it would be useful to have a similar warning like "SCREPL01: 'var' is not defined in the local environment," or something, which you might implement in…

Thank you, and thanks for the suggestion. Yes, it should be possible to keep the SC2154 check. I probably just disabled it as a quick fix when first started out. I'm tracking this in https://github.com/HenrikBengtsson/shellcheck-repl/issues/15.

> You'd also want to take into account special variables like $RANDOM and $HOSTNAME, but that's pretty trivial.

It seems like ShellCheck is already aware of these special Bash variable, e.g. 'echo $RANDOM' will not trigger SC2154 (or even SC2086 that otherwise asks you to quote variables).

Re: Bash Pitfalls

#34

Post by nerdyadventurer »

HenrikB wrote: post #19

(Disclaimer: I'm the co-developer) Together with GitHub user xPMo, I created a Shellcheck REPL tool ( https://github.com/HenrikBengtsson/shellcheck-repl ) that validates your Bash commands using ShellCheck _before_ they are evaluated. For example, $ words="lorem ipsum dolor" $ echo $words ^-- SC2086: Double quote to prevent globbing and word splitting. It was a toy project at first, but since I've learned so much abo…

I am not an expert, so forgive me for asking, Does Zsh also has this pitfalls?

Re: Bash Pitfalls

#35

Post by ttanev »

HenrikB wrote: post #19

(Disclaimer: I'm the co-developer) Together with GitHub user xPMo, I created a Shellcheck REPL tool ( https://github.com/HenrikBengtsson/shellcheck-repl ) that validates your Bash commands using ShellCheck _before_ they are evaluated. For example, $ words="lorem ipsum dolor" $ echo $words ^-- SC2086: Double quote to prevent globbing and word splitting. It was a toy project at first, but since I've learned so much abo…

A very happy and grateful user here, jumping in here just to thank you for the time and efforts to create this one! It saved me many hours of debugging after stupid midnight-coding-sessions mistakes. We even have it in our coding-style internal guidelines for some time now.
Post reply on HN