bash and input type detection...

hi,
as far as i know there are 2 ways to pass input data to a bash function:

1) via standard input

  func_name < data.txt
  func_name <<< "${data}"

2) via positional parameters:
a. passing input data filename

  func_name "data.txt"

b. passing the data variable

  func_name "${data}"

c. passing the data var name and then declaring it by reference

  function func_name () {
    declare -n input_data=$1
    ...
  }
  func_name data

what is the best way to deal with all of these options, so that you can remember which input way should be used with each function you write?

would it be a good idea to write a helper function to detect the input type and pass it to the commands of the main function?

i mean something like this:

function main () {

  declare input=$(__input_detect "$@")
  
  cat ${input}

  return 0
}

function __input_detect () {

  # check if standard input is present
  if read -t0; then
    echo "< /dev/stdin"
    return 0
  fi
  
  [[ -z ${1+x} ]] \
    && retun 0
    
  # check if $1 is a valid file name
  if [[ -f $1 ]]; then
    echo "$1"
  # check if $1 is the name of an existing variable
  elif [[ ! -z ${!1+x} ]]; then
    echo "<<< \"${!1}\""
  else
    echo "<<< \"$1\""
  fi
  
  return 0

}

# all of these invocation ways should work:
main_func data.txt
main_func < data.txt
main_func <<< "${data}"

# and these should not (so far):
main_func "${data}"
main_func data

this example is only partially working, but i'm posting it just to let you understand what i mean...

do you think such an input detection is somehow useful, or is it just a waste of time?

One common convention in UNIXland is to treat a filename of '-' as meaning read from stdin instead. Some programs may even default to this behavior when no arguments are specified.

I'd recommend you follow that design wherever it makes sense to do so.

i understand the question.

my question is:

why?

is there an actual problem that needs solving, or is this pure curiosity?

Can you simply do the following?

main(){
    cat "$@"
}
main "$@"

The "$@" passes the input properly:
the function or the cat run on the given arguments or from stdin if no arguments.

Originally Posted by ondoho i understand the question. my question is: why? is there an actual problem that needs solving, or is this pure curiosity?

curiosity, mostly...

i've always thought that stdin was the most convenient way to pass input to a program but found it very expensive when processing large data amounts.

so i found myself having most of the programs processing stdin only and some other processing input text files only, that made me sometimes wonder 'how does that work..?'

then i discovered how to pass variables by reference, started using it in some programs and the occasional indecision i mentioned before became pretty usual...

so the actual question: am i the only one in the world who can't remember how to properly invoke his own scripts? if not (as i hope), how others solved this? maybe by making their programs accepting any type of input? if so, how?

Originally Posted by masavini so the actual question: am i the only one in the world who can't remember how to properly invoke his own scripts? if not (as i hope), how others solved this? maybe by making their programs accepting any type of input? if so, how?

I usually include a check of the input and a usage example...

($email, $ipaddr, $fwdmsg) = @ARGV;

if (!$email || !$ipaddr || !$fwdmsg) {
	print "usage is: sndspamrpt.pl <abuse email> <ip> <filename>\n";
	print " example: sndspamrpt.pl abuse\@somedomain.com 123.456.798.23 /home/postmaster/Maildir/db/new/msg.ABCD\n";
	exit;
}

So,when run without arguments we get

sndspamrpt.pl 
usage is: sndspamrpt.pl <abuse email> <ip> <filename>
 example: sndspamrpt.pl abuse@somedomain.com 123.456.798.23 /home/postmaster/Maildir/db/new/msg.ABCD

Do that when you create the script and it will remind you what to do.

Like scasey, a good usage message never goes astray and can be triggered by other the wrong number / type of arguments or maybe with a helper option such as -h or --help

I would add that everything passed to a function is actually read in as a string, ie when passing the name of a file to a function / script at the exact time of being called it is
not a file name but just a simple string. It would not be until it is used by something that reads / tests files that you would now if it were actually the name of a file

#-------------------------------------------------------------------------------
# Overview: Provide usage information for script
#
# Function:   run_instructions
#
# Parameters: NA
#
# Return:     usage message
#-------------------------------------------------------------------------------
run_instructions()
{
  cat<<-USAGE
   
    Usage: ${0##*/} [switch] [file|type]
  
    Switch:
        -d, --defaults        User can use default values
        -i, --info [type]     Request field information on type
        -t, --template [name] Create template install file
        -v, --verbose         Allows system commands to show verbose output, eg. chmod -v
        -h, --help            Display this help message
  
    File:
        file              Name of File List to use in script
        type              Type to be used in input file
        name              Name to be used for input file creation
  
    Aborted : $(date)
  
  USAGE

  exit 1
} #run_instructions

So the above is my standard format for a usage message and a simple test to get this up would be:

for opt
do
  case "$opt" in
    ...) #other options here
    -h|--help|*) run_instructions;;
  esac
done

You obviously need to process the other parameters which are not option / switches but you get the general idea
So you would be able to call your script as:

./your_script.sh -h

And get a listing of what is accepted as input