March 4, 2019 at 12:05 am
Comments posted to this topic are about the item Parameter Fun
March 4, 2019 at 6:34 am
For Unix tools, the usual convention is that a single dash is for 1-letter parameters, and the double-dash for full named parameters (e.g. -h and --help, or -v / --verbose)
/ for parameters is a Windows-ism, so it's not unexpected that it won't work on Unix.
March 4, 2019 at 8:55 am
Linux is base on Unix, which was written by programmers for programmers. One of the beauties of Unix was how much work could be accomplished with very few keystrokes. Back in the day, there would not be "-?" as an argument for any Unix command. There might be "-h". But if you really wanted to know about a command, say sqlcmd, you would use "man sqlcmd" to print the manual pages for sqlcmd on the screen.
March 4, 2019 at 10:24 am
man command is something I used to use often. I just find it to be a poor design decision, but a clever one, that "-af" is "-a -f". It's short sighted to assume all parameters would be single character.
March 4, 2019 at 11:53 am
Steve Jones - SSC Editor - Monday, March 4, 2019 10:24 AMman command is something I used to use often. I just find it to be a poor design decision, but a clever one, that "-af" is "-a -f". It's short sighted to assume all parameters would be single character.
http://www.catb.org/~esr/writings/taoup/html/ch10s05.html has a pretty good discussion. Seems like "dash followed by single character" isn't universal, the old X toolkit didn't use that convention.
March 4, 2019 at 2:57 pm
Steve Jones - SSC Editor - Monday, March 4, 2019 10:24 AMman command is something I used to use often. I just find it to be a poor design decision, but a clever one, that "-af" is "-a -f". It's short sighted to assume all parameters would be single character.
That's why the convention is --param for parameters that aren't single characters.
March 4, 2019 at 3:44 pm
I should unpack that a little more. The fundamental Unix conventions were established in the 1960s and 1970s, when computers were far more limited in CPU, memory, and network bandwidth. Every keystroke counted; being able to type 'ls -slApF' instead of 'ls -s -l -A -p -F' was a significant savings in time and resources (nevermind 'ls --size -l --almost-all --indicator-style=slash --classify', which wasn't even an option in the early days!). Was it hard to read? Sure, but it worked! Cheat sheets were common, but any command one used frequently became second nature, plus 'alias' let you encapsulate a longer command in a short string.
Over time, as bandwidth increased and other resources became more plentiful, readability and memorability became bigger concerns, and some commands started running out of single letters that were in use, especially letters that had any connection to the parameter. But breaking everything that used the original format -- including user habits -- would be a really bad idea, so the -- predicate for multi-character parameters was introduced. The most commonly used options still have short names for efficiency; less-common options may only have a long name, and many options have both, because there's more than one way to do it, as Perl programmers say.
I'm oversimplifying a bit -- other conventions have been used and sometimes still are; some tools use a - for all parameters and don't allow combining, some use +/- to turn options on/off, etc. -- but that's the general idea.
'/' is a directory separator in Unix, so it would not work well as a parameter predicate.
March 4, 2019 at 4:13 pm
cmullican - Monday, March 4, 2019 3:44 PMI should unpack that a little more. The fundamental Unix conventions were established in the 1960s and 1970s, when computers were far more limited in CPU, memory, and network bandwidth. Every keystroke counted; being able to type 'ls -slApF' instead of 'ls -s -l -A -p -F' was a significant savings in time and resources (nevermind 'ls --size -l --almost-all --indicator-style=slash --classify', which wasn't even an option in the early days!). Was it hard to read? Sure, but it worked! Cheat sheets were common, but any command one used frequently became second nature, plus 'alias' let you encapsulate a longer command in a short string.Over time, as bandwidth increased and other resources became more plentiful, readability and memorability became bigger concerns, and some commands started running out of single letters that were in use, especially letters that had any connection to the parameter. But breaking everything that used the original format -- including user habits -- would be a really bad idea, so the -- predicate for multi-character parameters was introduced. The most commonly used options still have short names for efficiency; less-common options may only have a long name, and many options have both, because there's more than one way to do it, as Perl programmers say.
I'm oversimplifying a bit -- other conventions have been used and sometimes still are; some tools use a - for all parameters and don't allow combining, some use +/- to turn options on/off, etc. -- but that's the general idea.
'/' is a directory separator in Unix, so it would not work well as a parameter predicate.
I like using the convention of calling the -[char], --[keyword] etc switches or options, after all many commands have positional parameters too and it helps to keep them separate when putting together command lines. Obviously some switches have their own parameters too. I know thats probably just personal preference, but knowing that switches and parameters have a somewhat different meaning has helped me put together some working command lines with utilities that had lots of options and multiple parameters but will only offer something like "bad parameters" as a troubleshooting aid 🙂
March 4, 2019 at 4:24 pm
patrickmcginnis59 10839 - Monday, March 4, 2019 4:13 PMI like using the convention of calling the -[char], --[keyword] etc switches or options, after all many commands have positional parameters too and it helps to keep them separate when putting together command lines. Obviously some switches have their own parameters too. I know thats probably just personal preference, but knowing that switches and parameters have a somewhat different meaning has helped me put together some working command lines with utilities that had lots of options and multiple parameters but will only offer something like "bad parameters" as a troubleshooting aid 🙂
Fair enough. "Parameter" was used throughout the previous posts in the thread, so I stuck with it. I try to provide more useful error messaging when I control that; if I don't control it, I'm at the mercy of whatever terminology the developer chose anyway.
March 5, 2019 at 6:18 am
Steve Jones - SSC Editor - Monday, March 4, 2019 10:24 AMman command is something I used to use often. I just find it to be a poor design decision, but a clever one, that "-af" is "-a -f". It's short sighted to assume all parameters would be single character.
It seems pretty reasonable to me - how many commands take more than 26 parameters?
March 5, 2019 at 12:29 pm
It's not take, it's have. Not many do, but some do.
March 5, 2019 at 3:19 pm
Chris Wooding - Tuesday, March 5, 2019 6:18 AMSteve Jones - SSC Editor - Monday, March 4, 2019 10:24 AMman command is something I used to use often. I just find it to be a poor design decision, but a clever one, that "-af" is "-a -f". It's short sighted to assume all parameters would be single character.It seems pretty reasonable to me - how many commands take more than 26 parameters?
Since it's case sensitive -- -a and -A are different -- 52 is the number you'd have to exceed -- but it's actually larger, because numbers can be used (e.g. -1 for single column output), as well as some non-alphanumeric characters, although those are rare.
Viewing 12 posts - 1 through 11 (of 11 total)
You must be logged in to reply to this topic. Login to reply