4 ms·
I agree, but would like to add that people seem to forget all of the decency when writing shell scripts. They don’t do input checking and validation, they don’
by znpy 4y ago
I agree, but would like to add that people seem to forget all of the decency when writing shell scripts.
They don’t do input checking and validation, they don’t check for errors, return codes and stuff…
No wonder their scripts fail or do something completely unexpected.
Can you blame it on the shell?
No this is not a rhetorical question: you cannot blame the shell for your negligence and incompetence.
- bravetraveler 4y agoNot trying to be a pedant, I tend to agree, but isn't posing the question to give the statement/answer explicitly rhetorical? RE: > Can you blame it on the shell? > No this is not a rhetorical question: you cannot blame the shell for your negligence and incompetence. Asking largely out of confusion, I haven't completely woken up yet
- chasil 4y agoHow can you check that argv[1] is numeric and greater than zero? I've settled on this, recently, for my own use: i=$((${1} + 0)); [ "$i" -le 0 ] && { echo nope; exit; }
- znpy 4y agoi don't see the problem with what you wrote. also, you could use expr if you don't like fiddling with parentheses when dealing with numeric values.
- chasil 4y agoA fork() will be imposed with expr; using the shell's native math is faster. In any case, I have never seen "best practices" for (numeric) type coercion and confirmation. Everybody seems to come up with something on their own.
- ykonstant 4y agoIf I am reading the POSIX spec correctly, test 0 -lt "$1" 2>/dev/null || exit $?; should be enough to get what you want in a compatible shell.
- H4ZB7 4y ago> Can you blame it on the shell? yes, because the mere act of comparing two variables in bash is about 100x harder than any other language (not to mention it literally straight up adds undocumented RCE vectors to your code for example when you use [[...]])