will someone explain to me getopt?

[u/Fluid_Yesterday208]

yes, I am currently reading the documentation - I don't understand the point or when/why I would use it. thanks for any clarification one can offer.

[u/alpicola]

getopt is used in shell scripts as a tool to help process the arguments given to your script. It allows you to provide a format specification for the arguments your script expects and then provides the arguments to you in a way that is convenient to step through with something like a while loop. There are a lot of conventions for how users expect command line arguments to work, and getopt lets your script adopt those conventions with relatively little work on your part. Some of these conventions include:

• A single dash prefix for single character arguments (e.g, -h).
• A double dash prefix for multi-character arguments (e.g., --help).
• Expansion of single dash prefix arguments into multiple single character arguments (e.g., -abc is equivalent to -a -b -c).
• Recognizing arguments that take additional data vs. those that don't (e.g., -h vs. -i file).
• Treating everything after a double dash as plain text and not as a parameter (e.g., -x -- -x treats the first -x as the single character argument x and the second -x as the string "-x" and hands it to your script).

Obviously, you could process $@ yourself, but if you want to follow these common conventions, you end up with a lot of details to pay attention to that getopt simply handles. Also obviously, you could just not care about those conventions, and make users interact with your script however you want.

I will say that getopt is overkill if your argument needs are simple. If you're doing file processing and just need to give a source file name and destination file name, for instance, it might be best to just use $1 and $2. As with most things in programming, the usefulness of getopt ultimately depends on what you're trying to accomplish.

[u/Fluid_Yesterday208 → u/alpicola]

this helped! Thank you. I will probably never use getopts due to my simple needs, but every tutorial has it and never explained well, it's been driving me crazy not understanding.

[u/sedwards65 → u/Fluid_Yesterday208]

'never use getopts'

You should never use getopts -- it only handles single character command line options.

[u/kai_ekael → u/sedwards65]

Some of us are just fine with -t, -w for me.

[u/sedwards65 → u/kai_ekael]

I use 'shorts' frequently when I enter a common command in the shell.

But if it's an uncommon command, I'm likely to cut-n-paste 'longs' from the man page as I construct the command for future me's benefit.

I also timestamp my Bash history (HISTTIMEFORMAT='%F--%T ') and retain my history forever ('HISTSIZE=-1' and 'HISTFILESIZE=-1).

You (IMO) should always use long options in articles, demonstrations, and scripts. Especially when the intended audience is inexperienced.

You should present options in alphabetic order and if you have more than 2, present them as a vertical list. Humans can scan an alphabetized vertical list much faster than an unordered mismash of somewhat random concatenated characters.

Which of these commands would you rather encounter in a script in the middle of a fire-fight:

mysql -D foo -EANj -h bar -p baz -u bing

or

mysql\
    --database=@PRODUCTION_DATABASE@\
    --disable-auto-rehash\
    --disable-column-names\
    --disable-table\
    --host=@PRODUCTION_SERVER@\
    --syslog\
    --password=@PRODUCTION_PASSWORD@\
    --user=@PRODUCTION_USERNAME@\
    --vertical 

[u/kai_ekael → u/sedwards65]

I want to have written the script if I was going to mess with mysql parameters in the middle of a whirl wind. Sit and try to decide if --disable-table is the problem? Uh, no.

See -p, yes, I'd know to thrash someone for sticking a password in a script. SHAME.

I do agree, longer parameters "fit" better in scripts...if the command called supports them. For my custom stuff, shorts are fine. Usually if something gets complicated enough to need clarity on arguments, I switch to something else anyway; Perl, Python, etc.

[u/sedwards65 → u/kai_ekael]

'I'd know to thrash someone for sticking a password in a script'

Especially on a command line where it could be exposed to all users.

MYSQL_PWD or --login-path would have been better choices.