I am using getopt and setting `eval set -- "$opts"`. I find that most times `eval` is discouraged. What can I use instead?

opts=$( getopt -o "$shortopts" -l "$longopts" -n "${0##*/}" -- "$@" )
eval set -- "$opts"

I assume, as is the most common case, that you are using the BASH shell.
#1 For integer operations you can use the built-in bash mathematics capability. This is adequate for all integer operations without calling any external binary. (See https://www.linuxscrew.com/bash-math-arithmetic for example and a more detailed and educational discussion at https://www.shell-tips.com/bash/math...c-calculation/.)

#2 for doing floating point operations you can use the printf built-in as documented in the second article referenced above, or call the bc external.

The question is about an alternative to `eval` though.

I think the point is that you probably do not need eval at all to achieve what you want.

I do not quite understand your code example: What's the context?
What's in $opts?
Not saying there isn't one, but currently I cannot imagine a situation where a line like this would make any sense.

^What ondoho said.

Usually, just omitting the quotes would have the same effect:

The articles I referenced discuss eval and note that it is obsolete, and discuss what to do instead.
Perhaps reading one or both would help you.

@wpeckham. You confused eval with expr. The articles don't mention eval at all.

Curses (not ncurses), you are right and I was in error in that. Let me get back with better information.

Thus, it is not unreasonable to use "eval" under conditions where you tightly control or have extensively sanitized the arguments or data in question. the reason to find alternatives to "eval" is that it lends itself to exploits or unintended consequences of unexpected data or argument structures and content. In other words, it is a risk better avoided.

And here I come to the question that should have been the FIRST thing that I asked (shame on me, I should know better!) "What are you using "eval" for?". Followed by "what is the argument/opt data that you are sending, and is it ever not under your direct control?".

"getopts" (with an 's') is what you want. Much nicer and avoids the need for that horrible "eval set ..." mechanism.

What is the difference between

eval set -- "$opts"

and a direct call using

set -- "$opts"

is roughly equivalent to
without quotes. But there's a difference, and this is what makes eval so dangerous. Compare
to
Consider what will happen if you don't control the contents of $opts and instead of echo def there's rm -rf /.

1 members found this post helpful.

Without the 'eval' the shell will word split in the wrong places.
as can be seen, 'eval' is required for set to correctly reset the options from the string from getopt.

The issue with eval however is as shruggy describes above: it can be tricked into running commands, e.g.
Now, gnu getopt will quote that $( ) to prevent this sort of thing from happening (with a single eval), so it should be safe even with an 'eval', but because of this inherent issue with eval, most script-writers will recoil in horror when seeing one used. Also, not all implementations of getopt will even do this quoting, leaving them vulnerable.

So, in short, with the gnu implementation of getopt and using the -o syntax, you don't need to have any fears about using a single eval, but other implementations of getopt will likely not be safe.

1 members found this post helpful.

I used bash's built-in math capabilities.

Thanks a lot for the explanation.

This is the case when you need to use eval. If you wish to omit you need to use something else instead of getopt.