Been using UNIX since the late 80s; Linux since the mid-90s; virtualization since the early 2000s and spent the past few years working in the cloud space.
Location
Alexandria, VA, USA
Education
B.S. Psychology from Pennsylvania State University
You missed one of the really great BASHisms: <( COMMAND ). Basically, run command in a subshell, then return it's output through a file-descriptor. Meaning that you can do things like:
diff two streams
run a command within a shell to create an input-"file" for other commands that want input in the form of a file rather than a stream.
Another great one is VAR=($( COMMAND )) ...which takes the output from COMMAND and creates an array-variable from it.
Also useful is $( COMMAND )$? for when you care about how a command exited but not its output (e.g., you want to test to see if grep found a string in a file, [[ $( grep -q PATTERN FILE )$? ]].
Ryan is an engineer in the Sacramento Area with a focus in Python, Ruby, and Rust. Bash/Python Exercism mentor. Coding, physics, calculus, music, woodworking. Looking for work!
These are great! When I get in front of a keyboard, I’ll add them to the list! Thanks for sharing. What are the most common file-expecting commands you use the sub shell redirect with?
Been using UNIX since the late 80s; Linux since the mid-90s; virtualization since the early 2000s and spent the past few years working in the cloud space.
Location
Alexandria, VA, USA
Education
B.S. Psychology from Pennsylvania State University
AWS CLI for (particularly for CloudFormation) seems to not quite process STDIN for the --parameters flag as one might expect. Usually have to do something like what I put in my article when I'm doing stack-iterations as part of a quick test-change-test cycle (where "quick" is relative to things like RDS - there's frequently not enough time to wait for one launch to delete before moving on to the next launch).
Ryan is an engineer in the Sacramento Area with a focus in Python, Ruby, and Rust. Bash/Python Exercism mentor. Coding, physics, calculus, music, woodworking. Looking for work!
Been using UNIX since the late 80s; Linux since the mid-90s; virtualization since the early 2000s and spent the past few years working in the cloud space.
Location
Alexandria, VA, USA
Education
B.S. Psychology from Pennsylvania State University
Not sure what your experience is, but mine is that it works pretty much exactly as one would reasonably expect. It's functionally equivalent to executing something like:
<COMMAND>
if [[ $? ]]
then
…
But without any shell-linters bitching about using an inefficient execution-form.
That said, you need to be familiar with what the subshelled-command's likely outputs are going to be. Which is to say:
If the subshelled-command has an output other than just an exit code, you need to suppress it. Some commands have a built-in "quiet" option; for those that don't, you can suppress by redirecting output to /dev/null. Failing to suppress output will tend to cause evaluation-logic to evaluate as a string of <COMMAND_OUTPUT><COMMAND_EXITCODE> rather than an integer of <COMMAND_EXITCODE>.
Similarly, if you care to handle more than a -eq 0 or -ne 0 output, you need to be familiar enough with the given command's possible exit-codes to set up the appropriate handlers you might want/need.
Comment hidden by post author - thread only visible in this permalink
You totally misunderstand what [[ $? ]] actually does. It is actually equivalent to [[ -n $? ]], with -n being the operator for non-empty string test. Since $? always contains an exit status of the last command, it will always be a non empty string, so [[ $? ]] will always return 0 and evaluate to true in if context.
Please read up on how if works in bash and stop screwing up noobs with worthless code.
Been using UNIX since the late 80s; Linux since the mid-90s; virtualization since the early 2000s and spent the past few years working in the cloud space.
Location
Alexandria, VA, USA
Education
B.S. Psychology from Pennsylvania State University
Ok, so, I shortcut on my prior statement. The response was basically, "here's something you can start your Googling with," not, "here's a whole freaking book on the topic." But, congratulations, rage-boy, in your quest to service "noobs" (great to throw that term out there, btw: really shows your head-space and overall level of respect for your community-members), you've extended this thread beyond the scope of a simple Google-starter. And for all of that belaboring, the point still stands that there's many useful, reliable ways to use the $( command )$? construct. Clearly your opinion differs. Clearly you've been badly snakebitten (or otherwise simply have an axe to grind). However, like with any useful tool or construct, just because there are ways that it can fail within a given context, it's still useful when correctly used in the right contexts.
Ryan is an engineer in the Sacramento Area with a focus in Python, Ruby, and Rust. Bash/Python Exercism mentor. Coding, physics, calculus, music, woodworking. Looking for work!
Hi guys! Just FYI, I’ve muted and moderated both of your comments in this particular thread. Let’s try to keep it positive and helpful for the people who need this info next time. I’d appreciate it if you’d take any further posturing/bickering into dms and out of my comments. Thanks!
Been using UNIX since the late 80s; Linux since the mid-90s; virtualization since the early 2000s and spent the past few years working in the cloud space.
Location
Alexandria, VA, USA
Education
B.S. Psychology from Pennsylvania State University
No worries. After my final reply, I did a "who is this guy" click on his profile noticed that he'd apparently created an account just to piss on the thread (created the day he started thread-crapping and only activity shown on profile is the thread-crapping). So, had no further intent to respond.
Yes, I'm new here, but I'm not new. I write a LOT of bash on my job, so when I see these dangerous "recommendations", it makes me cringe.
And you, my friend, should reign in your prideful graphomania and actually TEST your code before you post it.
You have not demonstrated any useful way of using the $( command )$? construct. Your original one is dangerous and misleading. I'm asking you, please stop screwing over noobs - bash can be very unforgiving and can do a lot of damage when used incorrectly.
Some comments have been hidden by the post's author - find out more
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
You missed one of the really great BASHisms:
<( COMMAND ). Basically, run command in a subshell, then return it's output through a file-descriptor. Meaning that you can do things like:Another great one is
VAR=($( COMMAND ))...which takes the output fromCOMMANDand creates an array-variable from it.Also useful is
$( COMMAND )$?for when you care about how a command exited but not its output (e.g., you want to test to see if grep found a string in a file,[[ $( grep -q PATTERN FILE )$? ]].These are great! When I get in front of a keyboard, I’ll add them to the list! Thanks for sharing. What are the most common file-expecting commands you use the sub shell redirect with?
AWS CLI for (particularly for CloudFormation) seems to not quite process STDIN for the
--parametersflag as one might expect. Usually have to do something like what I put in my article when I'm doing stack-iterations as part of a quick test-change-test cycle (where "quick" is relative to things like RDS - there's frequently not enough time to wait for one launch to delete before moving on to the next launch).Thanks again for the tips! I just wanted to let you know that I updated the article with your suggestions. 😀
the
$( COMMAND )$?trick is a very bad one. Please don't advertise it, it basically NEVER works as you intend it to.Not sure what your experience is, but mine is that it works pretty much exactly as one would reasonably expect. It's functionally equivalent to executing something like:
But without any shell-linters bitching about using an inefficient execution-form.
That said, you need to be familiar with what the subshelled-command's likely outputs are going to be. Which is to say:
/dev/null. Failing to suppress output will tend to cause evaluation-logic to evaluate as a string of<COMMAND_OUTPUT><COMMAND_EXITCODE>rather than an integer of<COMMAND_EXITCODE>.-eq 0or-ne 0output, you need to be familiar enough with the given command's possible exit-codes to set up the appropriate handlers you might want/need.You totally misunderstand what
[[ $? ]]actually does. It is actually equivalent to[[ -n $? ]], with-nbeing the operator for non-empty string test. Since$?always contains an exit status of the last command, it will always be a non empty string, so[[ $? ]]will always return 0 and evaluate to true in if context.Please read up on how
ifworks in bash and stop screwing up noobs with worthless code.Ok, so, I shortcut on my prior statement. The response was basically, "here's something you can start your Googling with," not, "here's a whole freaking book on the topic." But, congratulations, rage-boy, in your quest to service "noobs" (great to throw that term out there, btw: really shows your head-space and overall level of respect for your community-members), you've extended this thread beyond the scope of a simple Google-starter. And for all of that belaboring, the point still stands that there's many useful, reliable ways to use the
$( command )$?construct. Clearly your opinion differs. Clearly you've been badly snakebitten (or otherwise simply have an axe to grind). However, like with any useful tool or construct, just because there are ways that it can fail within a given context, it's still useful when correctly used in the right contexts.Hi guys! Just FYI, I’ve muted and moderated both of your comments in this particular thread. Let’s try to keep it positive and helpful for the people who need this info next time. I’d appreciate it if you’d take any further posturing/bickering into dms and out of my comments. Thanks!
No worries. After my final reply, I did a "who is this guy" click on his profile noticed that he'd apparently created an account just to piss on the thread (created the day he started thread-crapping and only activity shown on profile is the thread-crapping). So, had no further intent to respond.
Yes, I'm new here, but I'm not new. I write a LOT of bash on my job, so when I see these dangerous "recommendations", it makes me cringe.
And you, my friend, should reign in your prideful graphomania and actually TEST your code before you post it.
You have not demonstrated any useful way of using the
$( command )$?construct. Your original one is dangerous and misleading. I'm asking you, please stop screwing over noobs - bash can be very unforgiving and can do a lot of damage when used incorrectly.