Bash function that accepts input from parameter or pipe

Question

I want to write the following bash function in a way that it can accept its input from either an argument or a pipe:

b64decode() {
    echo "$1" | base64 --decode; echo
}

Desired usage:

$ b64decode "QWxhZGRpbjpvcGVuIHNlc2FtZQo="
$ b64decode < file.txt
$ b64decode <<< "QWxhZGRpbjpvcGVuIHNlc2FtZQo="
$ echo "QWxhZGRpbjpvcGVuIHNlc2FtZQo=" | b64decode

Answer 1

See Stéphane Chazelas's answer for a better solution.

---

You can use /dev/stdin to read from standard input

b64decode()
{
    if (( $# == 0 )) ; then
        base64 --decode < /dev/stdin
        echo
    else
        base64 --decode <<< "$1"
        echo
    fi
}

• $# == 0 checks if number of command line arguments is zero
• base64 --decode <<< "$1" one can also use herestring instead of using echo and piping to base64

Answer 2

Here it should just be:

b64decode() {
  if [ "$#" -gt 0 ]; then
    # concatenated arguments fed via a pipe.
    printf %s "$@" | base64 --decode
  else
    base64 --decode  # read from stdin
  fi
  ret=$?
  echo # add one newline character
  return "$ret" # return with base64's exit status to report decoding
                # errors if any.
}

In any case, do not use base64 --decode < /dev/stdin. At best (on most systems) < /dev/stdin does nothing, it just does the equivalent of dup2(0,0) (duplicating fd 0 onto fd 0, a no-op).

But on Linux or Cygwin, < /dev/stdin does not work properly here. On those systems, opening /dev/stdin is not like duplicating stdin, it reopens from scratch and independently the same file as is currently opened on stdin.

So if previously stdin was pointing in the middle of some regular file, after < /dev/stdin, you'll end up with stdin now pointing at the start of that file. If stdin was the writing end of a pipe (which it shouldn't under normal circumstances), you'll end up with it being the reading end. If it was a socket, then it will fail as sockets cannot be opened. Same if you don't have permission to open that file for reading (for instance because the permissions changed or the file was originally opened on stdin using different credentials).

And after base64 --decode < /dev/stdin returns, the current position of stdin within the file (for seekable file input) will have been left untouched, not left at the end (or wherever base64 stopped reading) since base64's stdin was on a different open file description.

Answer 3

Sundeep's answer works for base64 because that utility does not support multiple lines. A more general fix for the more general case

• target utility allowing multiple commandline arguments
• pipe or redirect containing multiple lines

is something like

my_function() {
    if (( ${#} == 0 )) ; then
        while read -r line ; do
            target_utility "${line}"
        done
    else
        target_utility "${@}"
    fi
}

Answer 4

People are talking about how base64 --decode might really be a placeholder for a more complicated command — perhaps a pipeline or a compound command — but nobody does anything about it (*).  Well, here’s a non-recursive solution in which the main commands appear only once:

b64decode() {
        if [ "$#" -ne 0 ]
        then
                printf '%s\n' "$1"
        else
                cat
        fi | base64 --decode
        echo
} 

The logic is fairly simple:

• If there is an argument, write it to stdout.
  • (printf is safer than echo.)
  • The question doesn’t say what to do if there are two or more arguments, so I’m ignoring that case.
• If not, run a cat.
  • The lonesome cat isn’t useless.  UUOCs are typically characterized by having exactly one filename argument; this one has none.  It connects the input to the function (which is the input of the if statement) to the output of the if statement (which is the input to the base64 –decode statement), much like the cat in this slightly similar answer.

But some people are allergic to cats, so here’s a feline-free version:

b64decode() {
    (
        if [ "$#" -ne 0 ]
        then
                exec <<< "$1"
        fi
        base64 --decode
        echo
    )
}

• This uses a here-string, so it works in bash, and I guess it will work in ksh (ksh93 or higher), mksh and zsh, but it won’t work in other POSIX-compliant shells.
• The logic is similar to the first version — if there is an argument, redirect stdin to a here-string of the argument, so base64 will see it as stdin.
• Otherwise, do nothing (leave stdin alone).
• If the user says b64decode < file.txt, that (obviously) sets the stdin for the b64decode to be the file.txt file.  But, if we do any form of exec <…, that sets the stdin for the entire shell, globally.  So, after base64 has read the here-string, the shell will get an end-of-file (EOF) and exit.  So, we run the entire function in a subshell.  Of course this means that the processing code cannot do anything that changes the shell’s environment.

_______________
(*) Except for kbulgrien, who handled it with recursive code, which strikes me as inappropriate.

Answer 5

Both Sundeep's and TomRoche's answers were illuminating and appreciated, but in a different situation target_utility "${@}" could represent more complex code. Duplicating non-trivial code in both the if and in the else could create unnecessary issues. Though the OP's issue may not present a problem ideally resolved through use of recursion, other reader's problems may benefit from using it, or, from considering use of an wrapper function:

my_function() {
    if (( ${#} == 0 )) ; then
        while read -r __my_function ; do
            my_function "${__my_function}"
        done
    else
        target_utility "${@}"
    fi
}

This answer is one of various possible solutions for a "Bash function that accepts input from parameter or pipe" since the OP indicated [in a comment] that base64 was not the actual problem domain. As such, it makes no attempt to assure input is able to be directly read from a file.

Per various comments, there is concern this and similar other templates may not properly handle lines with leading white space; that IFS = may be required before the read. In fact, presence of any character the shell is sensitive to may require special handling before it hits this function. As-is, this code functions properly where leading white space is known to not occur, and where data sensitivities are pre-handled by the emitter.

This was not just a textbook example; it is used in an actual, production script. target_utility is a simple moniker for the actual code fragment. This answer does not presume to be a universal template without need for additional developer sagacity.

(It seems reasonable to assume users are often expected to occasionally adapt answers rather than expect to use them verbatim.)

Answer 6

Here is an example in the BSIP dialect of bash.

function vis_userAcctsReport {
G_funcEntry
function describeF {  G_funcEntryShow; cat  << _EOF_
Report on a user account, inputs can come from args or from stdin
Examples:
      ${G_myName} -i userAcctsReport bisos
      echo bisos bystar | ${G_myName} -i userAcctsReport
_EOF_
}
local inputsList="$@"
local thisFunc=${G_thisFunc}
function processEach {
EH_assert [[ $# -eq 1 ]]
local userAcctName=$1
if ! vis_userAcctsExist ${userAcctName} ; then
    EH_problem "${userAcctName} Does Not Exist -- ${thisFunc} Processing Skipped"
    lpReturn 101
fi
ANT_raw "--- ${userAcctName}: passwd, group, id, sudoers ---"
lpDo getent passwd ${userAcctName}
lpDo getent group ${userAcctName}
lpDo sudo -u ${userAcctName} id
lpDo sudo grep ${userAcctName} /etc/sudoers
}
if [ $# -gt 0 ] ; then
local each=""
for each in ${inputsList} ; do
    lpDo processEach ${each}
done
else
local eachLine=""
while read -r -t 1 eachLine ; do
    if [ ! -z "${eachLine}" ] ; then
    local each=""
    for each in ${eachLine} ; do
        lpDo processEach ${each}
    done
    fi
done
fi
lpReturn
}

Disclosure: This answer relates to "BSIF (ByStar Shell-based/bash-based Integration Facilities) Namespace: A name base for a collection of bash libraries and bash commands for autonomous services intgration [sic]." The answering party is the author/maintainer of the bsip package as represented at https://pypi.org/project/bsif/