A somewhat common claim is that "Z is a bash command", presumably because Z can be called from bash. For example, "sed is a bash command". At worst, this implies some sort of ownership or hierarchy that does not exist.
$ which sed
/usr/bin/sed
$ bash
ksh: bash: not found
How can sed be a bash command if bash is not installed on the system? (sed may also not be installed; the system is therefore not POSIX compliant. It is probably best to check such things, rather than to assume that a particular command exists and that the command behaves in particular ways.)
A historian might point to another problem,
HISTORY
A sed command first appeared outside of Bell Labs in PWB/UNIX
1.0. It was replaced in 4.4BSD.
and with some more legwork one might find claims that sed dates to 1974 and bash 1989; how something that is supposedly a bash command can exist for 15 years prior to bash being inflicted on the world is left as an exercise to the reader.
The claimant may retreat to a weaker claim, that sed can be run from bash. If so, is bash a perl command? Because bash can be run from perl,
$ perl -e 'system("bash") == 0 or die "nope: $!\n"'
or anything that can execute another command, which is a fair number of programs on a given unixlike. So that's not saying much, if anything.
Consider "sed, as shipped with OpenBSD 7.2", or "Fedora Linux awk". The sed is thus (probably) a BSD sed, and the awk most likely GNU awk, and we can find the documentation and source code for these, or with a little more work determine if that Fedora Linux awk is actually system-provided or instead is a special version living under /usr/local/bin or elsewhere.
Given "sed, a bash command", what can be derived?
"I want bash code that ..." may not actually be asking for bash code, given the confusion outlined above. A pure bash solution might be terrible, for instance anything involving looping with while, compared to using sed or whatever called from /bin/sh or whatever.
tags #bash #ksh #sed #perl