Earlier quoted context omitted.
Could you not do that with pipes instead, something like: $ diff
That's what the article is recommending.
[deleted]
Things I Wish I'd Known About Bash
191–200 of 272 posts
Re: Things I Wish I'd Known About Bash
#192rename -n 's/(.*)/new$1$2/' * There's a chance this won't work on your system. There are two incompatible versions of rename in the wild: 1) Perl one: https://metacpan.org/pod/distribution/File-Rename/rename.PL 2) from util linux: http://man7.org/linux/man-pages/man1/rename.1.html Debian (and dertivaties) ship the former; other Linux distros likely the latter.
I think this is not specific to the shell you are using, so it happens in bash, fish, ksh, zsh, and so on.
It’s misleading because rename is a command that accepts regex arguments. The shell isn’t doing anything more sophisticated with the quoted argument than passing it to rename as a positional parameter.
The shell of course does expand unquoted globs.
Re: Things I Wish I'd Known About Bash
#193Earlier quoted context omitted.
I don't know why not? At the least, rather than Bash, you might consider Perl as a default, lowest common denominator for scripts that need to run anywhere. - It's nearly as ubiquitous as bash. - It has approximately the same kinds of file/path operations built in. - It has reasonably good support for strings/regexes/etc. all built-in, so you don't have to call out to tools like sed/awk/grep all the time and hope tha…
Great point about ubiquity. Perl regexes are the best of breed that everyone else replicates — far better than “reasonably good.” The Perl erasure in this HN thread is startling.
> "The Perl erasure in this HN thread is startling."
"Erasure" to me implies some active effort to remove Perl from discourse. I don't see anything like that here: indeed, there are a number of positive mentions, and no negative ones I see. Granted, Python and Ruby are both mentioned more often, but none of those is at Perl's expense. Am I misunderstanding what you mean by 'erasure'?
Re: Things I Wish I'd Known About Bash
#194It's 2018 and we're still talking about writing non-trivial bash scripts?
Re: Things I Wish I'd Known About Bash
#195Earlier quoted context omitted.
I disagree. Here's how I decide: Do I need to manipulate rich data structures like hash-maps or nested lists? That sort of thing tends to stretch the capabilities of Bash to its limits and I tend to set the bar fairly low here. Is the program oriented around commands? If I'm gluing executable scripts and binaries, using bash is often superior to a scripting language. Argument passing is more natural and convenient an…
As someone who has to occasionally modify 100+ line bash scripts written by Coworkers from Christmas Past which matched your spec in terms of what they had to do, please please just use Python (or similar). Yes, you will have a few extra lines but it will be vastly more readable and maintainable. And yes, I know I will get the standard the person who wrote the script did a bad job but at some point it should be okay…
I think this might help others, but ShellCheck[0] is a good place to start to help eliminate poor shell scripting.
And I would make an argument though that even large shell scripts in bash have their place.
I often write scripts in either Node or Python, but only when I need things bash is bad about (any sort of proper data structure beyond strings or arrays).
But there are just so many things bash makes insanely easy, especially with operating on files and directories.
And functions that are used as completions or need access to aliases or functions in the current process are also better in bash.
I wish there were a scripting language like bash, but enhanced with at least some hash maps and proper array manipulation, and maybe some formal IPC to allow scripts to request info from the parent process.
Re: Things I Wish I'd Known About Bash
#196Blog states that author has 20 years of development experience.
Blog post suggests he knew little of basic shell scripting until recently.
Blog also reveals he is selling a book on shell scripting with Bash, "Learn Bash the Hard Way."
Re: Things I Wish I'd Known About Bash
#197For me, the biggest gotcha in bash is whether or not a sub-process/shell will be invoked, which can affect things like mutable variables and the number of open file handles. For example: COUNT=0 someCommand | while read -r LINE do COUNT=$(( COUNT + 1 )) done echo "$COUNT" This will always print `0`, since the `COUNT=` line will be run in a sub-process due to the pipe, and hence it can't mutate the outer-process's `CO…
I think I've run into the first issue you describe, and I'm having a hell of a time trying to understand it. Would you mind taking a look at my example and helping me out?
Consider the following:
cd /tmp/
echo -e "hello world\nhello world\n:)" >> hello.txt
cat hello.txt
hello world
hello world
:)
bash -c 'sed s/"hello"/"hiiii"/ hello.txt | tee hello.txt'
cat hello.txt
hiiii world
hiiii world
:)
ssh localhost -t 'cd /tmp && sed s/"hello"/"hiiii"/ hello.txt | tee hello.txt'
cat hello.txt
Replacing the command with
ssh localhost -t 'cd /tmp && sed s/"hello"/"hiiii"/ hello.txt >> hello.txt'
hello world
hello world
:)
hiiii world
hiiii world
:)
Re: Things I Wish I'd Known About Bash
#198Blog states that author has 20 years of development experience. Blog post suggests he knew little of basic shell scripting until recently. Blog also reveals he is selling a book on shell scripting with Bash, "Learn Bash the Hard Way."
> "Blog post suggests he knew little of basic shell scripting until recently."
I don't see how you could come to this conclusion based on the title. From the article, the author elaborates:
> "Recently I wanted to deepen my understanding of bash by researching as much of it as possible."
There seems to be a lot of good commentary in this thread indicating that people are finding the post useful. There are points here that I have. Do you have specific disagreements with the post contents?
Re: Things I Wish I'd Known About Bash
#199Earlier quoted context omitted.
Great point about ubiquity. Perl regexes are the best of breed that everyone else replicates — far better than “reasonably good.” The Perl erasure in this HN thread is startling.
> "The Perl erasure in this HN thread is startling." "Erasure" to me implies some active effort to remove Perl from discourse. I don't see anything like that here: indeed, there are a number of positive mentions, and no negative ones I see. Granted, Python and Ruby are both mentioned more often, but none of those is at Perl's expense. Am I misunderstanding what you mean by 'erasure'?
This is what Perl is designed to be. Perl unlike the others is almost certain to be on any Unix or Linux installation. Several commenters leaving out Perl in discussions of the next step up from bash scripts is truly strange.
I suppose being ignored beats the typical herp-derp anti-Perl bigotry, but I’d prefer all-around civility.
Re: Things I Wish I'd Known About Bash
#200For me, the biggest gotcha in bash is whether or not a sub-process/shell will be invoked, which can affect things like mutable variables and the number of open file handles. For example: COUNT=0 someCommand | while read -r LINE do COUNT=$(( COUNT + 1 )) done echo "$COUNT" This will always print `0`, since the `COUNT=` line will be run in a sub-process due to the pipe, and hence it can't mutate the outer-process's `CO…
I think I've run into the first issue you describe, and I'm having a hell of a time trying to understand it. Would you mind taking a look at my example and helping me out? Consider the following: cd /tmp/ echo -e "hello world\nhello world\n:)" >> hello.txt cat hello.txt Outputs: hello world hello world :) Then running bash -c 'sed s/"hello"/"hiiii"/ hello.txt | tee hello.txt' cat hello.txt yields hiiii world hiiii wo…
You're using hello.txt as both an input file and an output file, which seems like it's just asking for race-condition problems.
What about using sed -i to make changes to the file, and not doing any bash redirection?
Alternatively, if the real problem is more complex than that, try using a different name for the output file and rename after it's finished.