First one, then the other, then I forget the quotes, then I put them in single quotes by accident, then I utilize that “default value” colon syntax in case I’m missing HOME , then I just stick to ~ for the rest of the file.
@ilega_dh You don’t need cat in cases when grep "d" alphabet.txt can read from file too. Edit: But obviously your comment was more of a joke to over complicate it. So never mind then.
This comment is a joke and you wouldn’t want to do it like that in reality, but here are some related keywords you could look up: “Unix cat”, “Unix pipeline”, “grep”, “output redirection”, “command substitution”.
This has never stuck with me, and I hadn’t thought about why until now. I have two reasons why I will always write ${x}_$y.z instead of ${x}_${y}.z:
Syntax highlighting and shellcheck have always caught the cases I need to add braces to prevent $x_ being expanded as ${x_}.
I write a lot of Zsh. In Zsh, braces are optional in way more cases. "$#array[3]" actually prints the length of the third item in array, rather than (Bash:) the number of positional parameters, then the string 'array[3]'.
My reply is to a commenter who said they prefer "${HOME}/docs" over both options in the original image ("$HOME/docs" or "$HOME"/docs). Many people prefer to always include braces around the parameter name out of consistency, instead of only when they are required.
My comment explained why my habit is to only include braces when they are necessary.
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !programming@programming.dev
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person’s post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
Follow the programming.dev instance rules
Keep content related to programming in some way
If you’re posting long videos try to add in some form of tldr for those who don’t want to watch videos
Typically
find "$HOME/docs", but with a few caveats:In Zsh or Fish, the quotes are unnecessary:
find $HOME/docsIf I’m using anything potentially destructive:
mv "${HOME:?}/bin" ...Of course, if it’s followed by a valid identifier character, I’ll add braces:
"${basename}_$num.txt"First one, then the other, then I forget the quotes, then I put them in single quotes by accident, then I utilize that “default value” colon syntax in case I’m missing HOME , then I just stick to ~ for the rest of the file.
find “$(echo $HOME > variable_holder.txt && cat variable_holder.txt)/$(cat alphabet.txt | grep “d”) $(cat alphabet.txt | grep “o”)$(cat alphabet.txt | grep “c”)$(cat alphabet.txt | grep “s”)”
This is the easiest method
This really enterprises my bash.
no
eval?@ilega_dh You don’t need
catin cases whengrep "d" alphabet.txtcan read from file too. Edit: But obviously your comment was more of a joke to over complicate it. So never mind then.To be safe, should probably output grep to a file, then cat that.
Agreed. Everything in Linux is a file so let’s keep it that way.
Damn it, I’m almost out of A4 paper though.
What should I search to better understand what is written here? Don’t mind learning myself, just looking for the correct keywords. Thanks!
This comment is a joke and you wouldn’t want to do it like that in reality, but here are some related keywords you could look up: “Unix cat”, “Unix pipeline”, “grep”, “output redirection”, “command substitution”.
Perfect, I have some light reading for the evening!
ExplainShell should help
Read the Bash manual. That one patter on the GP is called “Command Substitution”, you can search for it.
Thanks!
when you’re paid by character written
cd $HOME/././././././././././././././././....just for kicks.@zephyr
echo "${HOME}/docs"I also do this so the variables are more easily spotted.
This is the way
This has never stuck with me, and I hadn’t thought about why until now. I have two reasons why I will always write
${x}_$y.zinstead of${x}_${y}.z:$x_being expanded as${x_}."$#array[3]"actually prints the length of the third item inarray, rather than (Bash:) the number of positional parameters, then the string'array[3]'.The difference between the two seems different to what’s in the OP. Is there a typo here?
My reply is to a commenter who said they prefer
"${HOME}/docs"over both options in the original image ("$HOME/docs"or"$HOME"/docs). Many people prefer to always include braces around the parameter name out of consistency, instead of only when they are required.My comment explained why my habit is to only include braces when they are necessary.
@gamma I just use them out of consistency and principle, so I don’t need to think in which case it is required or not.
This is the right way
This is the best way. It’s also the way the Shellcheck
wantssometimes recommends.This isn’t true. Shellcheck doesn’t insist on braces unless it thinks you need them.
Oh! I didn’t know that (um, obviously lol)
I’ll edit my comment.
@bloopernova As you mention it, here the links for anyone interested: Online tool https://www.shellcheck.net/ and you can install it locally too https://github.com/koalaman/shellcheck .
While this looks like a handy tool, it does make me think shell scripting itself needs a cleaner approach than what we have currently.
deleted by creator
deleted by creator
I do what the linter tells me to: https://github.com/koalaman/shellcheck