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).
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.
I don't get this pervasive myth that dang is some kind of robot slave who lives on managed time and 'copies' and 'pastes' things- dang is a real person who types every letter and loves every second of it.
It's dang's choice to have two windows open- one with the comment box, and one with the 'past' page- and to read which ones have discussion with his human eyes, and then to type out the relevant information into the comment box. I'm vicariously offended that anyone would think this is a task that should, or even could, be even partially automated.
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 about Bash from using it, I now have it enabled all the time.
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.
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.
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).
The title of this article brings to mind an imaginary platform game with controls so complex you have to have three browser tabs of instructions open to play it.
I am hopeful that the page will have a screenshot, when I am able to access it.
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.
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?
and still it's the only one which is easily available everywhere and for the most part already in the allow/whitelist of tooling in most organizations as redhat and debian/ubuntu are almost everywhere.
But practically everything unixy supports some shell variant that's similar to the others, so we have no choice in the matter. I compare this to PHP. They're both bad, PHP is a choice.
>The goal of this book is to document commonly-known and lesser-known methods of doing various tasks using only built-in bash features. Using the snippets from this bible can help remove unneeded dependencies from scripts and in most cases make them faster.
Bash Pitfalls - https://news.ycombinator.com/item?id=24401085 - Sept 2020 (111 comments)
Bash Pitfalls - https://news.ycombinator.com/item?id=10068567 - Aug 2015 (38 comments)
Bash Pitfalls - https://news.ycombinator.com/item?id=6790169 - Nov 2013 (54 comments)
Common Bash Pitfalls - https://news.ycombinator.com/item?id=869560 - Oct 2009 (25 comments)
Bash Pitfalls - https://news.ycombinator.com/item?id=52700 - Sept 2007 (1 comment)