Live data from Hacker News

Bash Pitfalls

mywiki.wooledge.org

21–30 of 35 posts

Re: Bash Pitfalls

#21
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 shellcheck-repl itself. That rule could simply check to see if 'var' exists in the current shell's environment or if it's defined in the user's current command.

I think bash is simple enough that you might not have to a full-blown parse on the input to pick out instances of variable use (just look for 'export var', 'unset var', 'var=', and the like). You'd also want to take into account special variables like $RANDOM and $HOSTNAME, but that's pretty trivial.

Re: Bash Pitfalls

#22
post #15

bash is a pitfall. In this world of IAC, powerful tools, unit testing, CICD, well crafted languages and libraries its a relic of an old time long gone.

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 it is the system architecture.

Re: Bash Pitfalls

#23
post #15

bash is a pitfall. In this world of IAC, powerful tools, unit testing, CICD, well crafted languages and libraries its a relic of an old time long gone.

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.

Amen to that. I second guess every line that I write in Bash that isn’t a simple command.

Re: Bash Pitfalls

#24
post #22

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…

So - if people instead could use a shell/script language that offers some more correctness/guarantees or fewer pitfalls, they will subconsciously make bugs in the system outside of that script because creativity?

Re: Bash Pitfalls

#25
post #9

Earlier quoted context omitted.

I often see your "related" comment at the top of these posts and they mostly seem to match what shows up when you click "past". Would it make sense to automatically add a prominent link to the most recent or most commented on post in the header so you wouldn't have to copy & paste the links as comments?

There are a lot of differences—you just have to squint to see them. I think a better solution would be software to let the community collaborate on building a related-links list. That could also naturally expand to including related URLs to articles on the same topic, even if they didn't get a previous HN conversation.

I want a related-comments tool, so that when anyone posts a comment on a story about Tesla Autopilot or nuclear energy, they can see links to the 10,000 unoriginal comments mirroring what they wrote (again).

Re: Bash Pitfalls

#26
post #22

Earlier quoted context omitted.

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…

So - if people instead could use a shell/script language that offers some more correctness/guarantees or fewer pitfalls, they will subconsciously make bugs in the system outside of that script because creativity?

If they dont get to be creative in solving the problem - if their job is simply to be a human emitter of YAML, then that creativity will be spent elsewhere.

Re: Bash Pitfalls

#27
post #26

Earlier quoted context omitted.

So - if people instead could use a shell/script language that offers some more correctness/guarantees or fewer pitfalls, they will subconsciously make bugs in the system outside of that script because creativity?

If they dont get to be creative in solving the problem - if their job is simply to be a human emitter of YAML, then that creativity will be spent elsewhere.

Not sure how we got from wishing we could use a language with fewer footguns than bash to… human emitter of YAML whose creativity has been ripped from them, so they will now design overly-clever systems as some sort of creative outlet?

Re: Bash Pitfalls

#28
post #25
post #9

Earlier quoted context omitted.

There are a lot of differences—you just have to squint to see them. I think a better solution would be software to let the community collaborate on building a related-links list. That could also naturally expand to including related URLs to articles on the same topic, even if they didn't get a previous HN conversation.

I want a related-comments tool, so that when anyone posts a comment on a story about Tesla Autopilot or nuclear energy, they can see links to the 10,000 unoriginal comments mirroring what they wrote (again).

There's something to that idea, because the art of optimizing a site for curiosity has mostly to do with avoiding repetition, and the most repetitive comments ought to be the most machine-learnable.

https://hn.algolia.com/?dateRange=all&page=0&prefix=true&sor...

https://hn.algolia.com/?dateRange=all&page=0&prefix=false&so...

https://hn.algolia.com/?dateRange=all&page=0&prefix=false&so...

Re: Bash Pitfalls

#29
See also:

* https://www.shellcheck.net/ — linting tool to avoid common mistakes and improve your script

* Bash Practices: https://mywiki.wooledge.org/BashGuide/Practices

* Bash FAQ: https://mywiki.wooledge.org/BashFAQ

* safe ways to do things in bash: https://github.com/anordal/shellharden/blob/master/how_to_do...

* better scripting: https://robertmuth.blogspot.in/2012/08/better-bash-scripting...

* robust scripting: https://www.davidpashley.com/articles/writing-robust-shell-s...

Post reply on HN