Script parameters in Bash
The script will then ocr convert the image file to a text file. Here is what I have come up with so far:
#!/bin/bash export HOME=/home/kristoffer /usr/local/bin/abbyyocr9 -rl Swedish -if . fromvalue. -of . tovalue. 2>&1 5 Answers 5
The arguments that you provide to a bashscript will appear in the variables $1 and $2 and $3 where the number refers to the argument. $0 is the command itself.
The arguments are seperated by spaces, so if you would provide the -from and -to in the command, they will end up in these variables too, so for this:
./ocrscript.sh -from /home/kristoffer/test.png -to /home/kristoffer/test.txt $0 # ocrscript.sh $1 # -from $2 # /home/kristoffer/test.png $3 # -to $4 # /home/kristoffer/test.txt It might be easier to omit the -from and the -to , like:
ocrscript.sh /home/kristoffer/test.png /home/kristoffer/test.txt $1 # /home/kristoffer/test.png $2 # /home/kristoffer/test.txt The downside is that you’ll have to supply it in the right order. There are libraries that can make it easier to parse named arguments on the command line, but usually for simple shell scripts you should just use the easy way, if it’s no problem.
/usr/local/bin/abbyyocr9 -rl Swedish -if "$1" -of "$2" 2>&1 The double quotes around the $1 and the $2 are not always necessary but are adviced, because some strings won’t work if you don’t put them between double quotes.
If you’re not completely attached to using «from» and «to» as your option names, it’s fairly easy to implement this using getopts:
while getopts f:t: opts; do case $ in f) FROM_VAL=$ ;; t) TO_VAL=$ ;; esac done getopts is a program that processes command line arguments and conveniently parses them for you.
f:t: specifies that you’re expecting 2 parameters that contain values (indicated by the colon). Something like f:t:v says that -v will only be interpreted as a flag.
opts is where the current parameter is stored. The case statement is where you will process this.
$ contains the value following the parameter. $ for example will get the value /home/kristoffer/test.png if you ran your script like:
ocrscript.sh -f /home/kristoffer/test.png -t /home/kristoffer/test.txt
As the others are suggesting, if this is your first time writing bash scripts you should really read up on some basics. This was just a quick tutorial on how getopts works.
@Zelphir, you can specify two or more flags simply ommiting the «:» after the flag. For instance f:t:vs will be -f some_f -t some_t -v -s
Use the variables «$1» , «$2» , «$3» and so on to access arguments. To access all of them you can use «$@» , or to get the count of arguments $# (might be useful to check for too few or too many arguments).
I needed to make sure that my scripts are entirely portable between various machines, shells and even cygwin versions. Further, my colleagues who were the ones I had to write the scripts for, are programmers, so I ended up using this:
for ((i=1;i <=$#;i++)); do if [ $= "-s" ] then ((i++)) var1=$; elif [ $ = "-log" ]; then ((i++)) logFile=$; elif [ $ = "-x" ]; then ((i++)) var2=$; elif [ $ = "-p" ]; then ((i++)) var3=$; elif [ $ = "-b" ]; then ((i++)) var4=$; elif [ $ = "-l" ]; then ((i++)) var5=$; elif [ $ = "-a" ]; then ((i++)) var6=$; fi done; Rationale: I included a launcher.sh script as well, since the whole operation had several steps which were quasi independent on each other (I'm saying "quasi", because even though each script could be run on its own, they were usually all run together), and in two days I found out, that about half of my colleagues, being programmers and all, were too good to be using the launcher file, follow the "usage", or read the HELP which was displayed every time they did something wrong and they were making a mess of the whole thing, running scripts with arguments in the wrong order and complaining that the scripts didn't work properly. Being the choleric I am I decided to overhaul all my scripts to make sure that they are colleague-proof. The code segment above was the first thing.
How to pass all arguments passed to my Bash script to a function of mine? [duplicate]
Let's say I have a function abc() that will handle the logic related to analyzing the arguments passed to my script. How can I pass all arguments my Bash script has received to abc() ? The number of arguments is variable, so I can't just hard-code the arguments passed like this:
Possible duplicate of Propagate all arguments in a bash shell script. (This question was actually posted before the one linked here. But the one in the link has more detailed answers and a more informative title and may be best as the reference question)
7 Answers 7
The $@ variable expands to all command-line parameters separated by spaces. Here is an example.
When using $@ , you should (almost) always put it in double-quotes to avoid misparsing of arguments containing spaces or wildcards (see below). This works for multiple arguments. It is also portable to all POSIX-compliant shells.
It is also worth noting that $0 (generally the script's name or path) is not in $@ .
The Bash Reference Manual Special Parameters Section says that $@ expands to the positional parameters starting from one. When the expansion occurs within double quotes, each parameter expands to a separate word. That is "$@" is equivalent to "$1" "$2" "$3". .
Passing some arguments:
If you want to pass all but the first arguments, you can first use shift to "consume" the first argument and then pass "$@" to pass the remaining arguments to another command. In Bash (and zsh and ksh, but not in plain POSIX shells like dash), you can do this without messing with the argument list using a variant of array slicing: "$" will get you the arguments starting with "$3" . "$" will get you up to four arguments starting at "$3" (i.e. "$3" "$4" "$5" "$6" ), if that many arguments were passed.
Things you probably don't want to do:
"$*" gives all of the arguments stuck together into a single string (separated by spaces, or whatever the first character of $IFS is). This looses the distinction between spaces within arguments and the spaces between arguments, so is generally a bad idea. Although it might be ok for printing the arguments, e.g. echo "$*" , provided you don't care about preserving the space within/between distinction.
Assigning the arguments to a regular variable (as in args="$@" ) mashes all the arguments together like "$*" does. If you want to store the arguments in a variable, use an array with args=("$@") (the parentheses make it an array), and then reference them as e.g. "$" etc. Note that in Bash and ksh, array indexes start at 0, so $1 will be in args[0] , etc. zsh, on the other hand, starts array indexes at 1, so $1 will be in args[1] . And more basic shells like dash don't have arrays at all.
Leaving off the double-quotes, with either $@ or $* , will try to split each argument up into separate words (based on whitespace or whatever's in $IFS ), and also try to expand anything that looks like a filename wildcard into a list of matching filenames. This can have really weird effects, and should almost always be avoided. (Except in zsh, where this expansion doesn't take place by default.)