06 Sep, 2008, Kayle wrote in the 2nd comment:
For something like grub from Smaug1.4 and I think it's still in 1.8 that would be amazingly useful. grub had/has such an obscure syntax, I'd always have to read and reread the helpfiles before I'd be able to get it to output what I wanted.
But yes, for some things, I can see that being an amazing tool, while for others, it'd be a bit of a waste because of the simplicity of their arguments.
But yes, for some things, I can see that being an amazing tool, while for others, it'd be a bit of a waste because of the simplicity of their arguments.
06 Sep, 2008, David Haley wrote in the 3rd comment:
I agree that for simple commands it is overkill and perhaps it would even hurt things by making it too complicated. But the commands I had in mind were precisely those big, complicated commands with several arguments.
It's nice to have a Lua library all ready to do this. :wink:
It's nice to have a Lua library all ready to do this. :wink:
06 Sep, 2008, Sandi wrote in the 4th comment:
When I was running a MUSH, I made a comprehensive stat-like command that took flags to display each line. For simplicity,the command itself was '=-'. So, if you want the full scoop on Joe, you'd enter '=- joe'. If you just wanted to see Joe's email, you could enter '=- -e joe'. Or, you could see the name and description of a group of players with, '=- -nd joe nancy bill tom sally'.
When I introduced it, I told my Linux using friends "It works just like you'd expect.", and they were very happy with it. The Windows users on the staff, however, never seemed to fully grok it. :rolleyes:
When I introduced it, I told my Linux using friends "It works just like you'd expect.", and they were very happy with it. The Windows users on the staff, however, never seemed to fully grok it. :rolleyes:
06 Sep, 2008, Cratylus wrote in the 5th comment:
DavidHaley said:
Is this syntax fine, cumbersome, useful, useless, …?
In my experience it's extremely valuable. The kind of muds I'm used to
provide an "OS-like" experience for developers, in that there is file management
and such:
Quote
Dead Souls /tmp >
ls -la
/tmp:
rw- Fri Jul 18 12:47:17 2008 42 .dead.edit
rw- Fri Mar 28 19:57:03 2008 228 1
rw- Sun Aug 3 05:53:24 2008 497 champ.bb
rw- Sun Jul 13 15:27:43 2008 38 cratylus.codesay
rw- Sun Jul 13 15:27:43 2008 1 cratylus.codesay_rule
rw- Tue Jul 8 14:20:00 2008 95 fizban.codesay
rw- Tue Jul 8 14:20:00 2008 1 fizban.codesay_rule
rw- Sun Mar 23 18:35:27 2008 292 foo
rw- Sat Aug 30 19:16:52 2008 2982142 imc2.log
rw- Sat Jul 5 19:21:12 2008 4309 lpmuds-forum
rw- Thu Sep 4 06:27:45 2008 386 muds.txt
rw- Fri Jun 27 22:08:54 2008 48 ntldr.txt
rw- Sun Jun 1 13:17:51 2008 9605669 pkt.txt
rw- Tue May 13 14:43:45 2008 882 queeny.txt
rw- Wed Aug 20 16:01:47 2008 80 raudhrskal.bb
rw- Mon Aug 14 13:44:49 2006 102049 showfuns.o
rw- Fri Jul 18 12:48:54 2008 4 skuld.bb
rw- Tue Aug 26 10:15:46 2008 -2 suicide/
rw- Sat Sep 6 04:28:09 2008 269 thingy.txt
rw- Mon Apr 14 04:57:17 2008 99 vache.txt
ls -la
/tmp:
rw- Fri Jul 18 12:47:17 2008 42 .dead.edit
rw- Fri Mar 28 19:57:03 2008 228 1
rw- Sun Aug 3 05:53:24 2008 497 champ.bb
rw- Sun Jul 13 15:27:43 2008 38 cratylus.codesay
rw- Sun Jul 13 15:27:43 2008 1 cratylus.codesay_rule
rw- Tue Jul 8 14:20:00 2008 95 fizban.codesay
rw- Tue Jul 8 14:20:00 2008 1 fizban.codesay_rule
rw- Sun Mar 23 18:35:27 2008 292 foo
rw- Sat Aug 30 19:16:52 2008 2982142 imc2.log
rw- Sat Jul 5 19:21:12 2008 4309 lpmuds-forum
rw- Thu Sep 4 06:27:45 2008 386 muds.txt
rw- Fri Jun 27 22:08:54 2008 48 ntldr.txt
rw- Sun Jun 1 13:17:51 2008 9605669 pkt.txt
rw- Tue May 13 14:43:45 2008 882 queeny.txt
rw- Wed Aug 20 16:01:47 2008 80 raudhrskal.bb
rw- Mon Aug 14 13:44:49 2006 102049 showfuns.o
rw- Fri Jul 18 12:48:54 2008 4 skuld.bb
rw- Tue Aug 26 10:15:46 2008 -2 suicide/
rw- Sat Sep 6 04:28:09 2008 269 thingy.txt
rw- Mon Apr 14 04:57:17 2008 99 vache.txt
(Note that non-dev players don't get access to this kind of stuff)
Even without file management and editing commands, though,
flags are very helpful for commands that manage/display data:
Quote
Dead Souls /tmp >
help groupmod
Syntax: groupmod [-a|-r] GROUP NAME
groupmod [-c|-d] GROUP
Modifies /secure/cfg/groups.cfg with the desired information.
To create a group called MUDKIPZ: groupmod -c mudkipz
To add Yotsuba as member of that group: groupmod -a mudkipz yotsuba
help groupmod
Syntax: groupmod [-a|-r] GROUP NAME
groupmod [-c|-d] GROUP
Modifies /secure/cfg/groups.cfg with the desired information.
To create a group called MUDKIPZ: groupmod -c mudkipz
To add Yotsuba as member of that group: groupmod -a mudkipz yotsuba
Quote
Dead Souls /tmp >
help people
Syntax: people [-abceghlmnprsu]
Gives you a listing of people on Dead Souls. Output is formatted into columns
with the following meanings:
amount of time spent total on Dead Souls
level
name
address from which the person is connecting
amount of time idle
blocking information, if any… A is all, C cre, G gossip
current environment file name
Command flags have the following meanings:
-a list all arches
-b list all ambassadors
-c list all non-arch creators
-e sort the listing by race
-g sort the listing by age
-h list all high mortals
-l sort the listing by level
-m pipe the listing through the more pager
-n list all newbies
-p list all non-newbie and non-high mortal mortals
-r sort the listing by current environment
-s sort the listing by class
-u list all undead people
People in the editor or
in mail or posting will be marked with []. People who
are invisible to others, but not to you will be marked with (). The default
sort is by arch, then by creator, then by ambassador, then by level. You can
perform multiple sorts, but you cannot change the priority. Sorts priority is:
class, race, realm, level, age. You can also include multiple groups in your
listing.
See also: who, users
help people
Syntax: people [-abceghlmnprsu]
Gives you a listing of people on Dead Souls. Output is formatted into columns
with the following meanings:
amount of time spent total on Dead Souls
level
name
address from which the person is connecting
amount of time idle
blocking information, if any… A is all, C cre, G gossip
current environment file name
Command flags have the following meanings:
-a list all arches
-b list all ambassadors
-c list all non-arch creators
-e sort the listing by race
-g sort the listing by age
-h list all high mortals
-l sort the listing by level
-m pipe the listing through the more pager
-n list all newbies
-p list all non-newbie and non-high mortal mortals
-r sort the listing by current environment
-s sort the listing by class
-u list all undead people
People in the editor or
in mail or posting will be marked with []. People who
are invisible to others, but not to you will be marked with (). The default
sort is by arch, then by creator, then by ambassador, then by level. You can
perform multiple sorts, but you cannot change the priority. Sorts priority is:
class, race, realm, level, age. You can also include multiple groups in your
listing.
See also: who, users
It's interesting to me that you'd have muds without flag-optioned commands.
In looking through my lib for examples, I noticed that for the most part
they involve commands that list data, or force options (-f) or recursive
options (-r), which may just not be of frequent use on Diku-derivs.
Dunno. I can just tell you I'd be sad on my LP mud if I couldn't have flags.
-Crat
http://lpmuds.net
06 Sep, 2008, David Haley wrote in the 6th comment:
Thanks for your replies. It is interesting that this seems to be an old concept on LP MUDs but I had never heard of it on Dikurivatives.
Hmmmmmmm… :lol:
I'm hoping that the learning curve won't be too bad. I started trying to figure out a syntax for the issue tracker I mentioned above without the options, and it was either going to be a terrible mess on the coding side, trying to figure out what was meant by matching against known values, or have a huge number of sub-commands to switch off of (and remember). So it really would make my life easier if the options syntax were to be accepted.
Sandi said:
When I introduced it, I told my Linux using friends "It works just like you'd expect.", and they were very happy with it. The Windows users on the staff, however, never seemed to fully grok it. :rolleyes:
Hmmmmmmm… :lol:
I'm hoping that the learning curve won't be too bad. I started trying to figure out a syntax for the issue tracker I mentioned above without the options, and it was either going to be a terrible mess on the coding side, trying to figure out what was meant by matching against known values, or have a huge number of sub-commands to switch off of (and remember). So it really would make my life easier if the options syntax were to be accepted.
06 Sep, 2008, The_Fury wrote in the 7th comment:
I have thought about doing something like this in my own base. Something that i have always found troubling was the lack of cohesion between various functions in smaug, even from a command point with redit, mset, oset. I never really understood why redit was not called rset, or all the other set commands were not called edits. It makes some sence to me to change the arguments of those commands to dash style arguments even if it is just to save on typing. -f seems much more convenient to type than say flags, sure its only 3 chars, but that can add up over the period of a session and might provide a substantial time saving.
07 Sep, 2008, Guest wrote in the 8th comment:
I find it somewhat amusing that people are complaining about the lack of cohesion in arguments to MUD related commands when most folks don't seem to have issue with it. Provided there's some kind of helpfile for the command if it's not well understood for some reason.
What I often get complaints about with people who don't have much linux shell experience is the utter lack of cohesion with all the stupid switch arguments to commands. Even with as much as I know about the stuff I find the lack of consistentcy in commands that use them to be an extreme source of frustration. And when consulting the helpfiles ( aka man pages ) it doesn't help to resolve that frustration very well since you end up flooded with hoardes of switches you didn't even know the command had. I also note that a lot of this is being paved over by decent GUI apps. Unfortunately allowing remote shell users access to a GUI leads to bandwidth issues.
I really don't think it would help spur growth in muds to start turning their administration commands into engineering lessons in order for people to learn how to use them. It's very off-putting.
What I often get complaints about with people who don't have much linux shell experience is the utter lack of cohesion with all the stupid switch arguments to commands. Even with as much as I know about the stuff I find the lack of consistentcy in commands that use them to be an extreme source of frustration. And when consulting the helpfiles ( aka man pages ) it doesn't help to resolve that frustration very well since you end up flooded with hoardes of switches you didn't even know the command had. I also note that a lot of this is being paved over by decent GUI apps. Unfortunately allowing remote shell users access to a GUI leads to bandwidth issues.
I really don't think it would help spur growth in muds to start turning their administration commands into engineering lessons in order for people to learn how to use them. It's very off-putting.
07 Sep, 2008, The_Fury wrote in the 9th comment:
Oh i wasn't complaining about it, rather just making mention that it was something that i have considered changing at some point, i did change redit to rset about 6 months back just to make those commands more in line with each other, funny thing was the few people who i had building at the time could not realy cope with the change and i never looked much into changing the arguments to something else.
I will agree with you on the Nix* command line and man pages, they can be an absolute nightmare to the uninitiated and should be used as a lesson not to ever let programmers and tech types write help files for non tech types.
I will agree with you on the Nix* command line and man pages, they can be an absolute nightmare to the uninitiated and should be used as a lesson not to ever let programmers and tech types write help files for non tech types.
07 Sep, 2008, David Haley wrote in the 10th comment:
So how would you solve the problem, Samson? When you have a command that has many, many switches and options, most or all of which are optional, how would you set up the syntax? I'm not saying that dash-style options are the best solution (if I were I wouldn't have opened this thread) but I'm not seeing another practical solution at the moment. I'm also not sure that the current system is necessarily all that simple to use.
I think it might be interesting to note that most people don't really complain too much about the command syntax because they have no choice in the matter. I've been told by my builders that command syntax is terrible, and I tell them that they can have me revamp the syntax or add new functionality; most of the time they prefer the latter over the former, but that doesn't change the fact that they really dislike positional syntax when you have 4+ arguments to line up.
FWIW I'm not sure they were written for non-tech types.
I think it might be interesting to note that most people don't really complain too much about the command syntax because they have no choice in the matter. I've been told by my builders that command syntax is terrible, and I tell them that they can have me revamp the syntax or add new functionality; most of the time they prefer the latter over the former, but that doesn't change the fact that they really dislike positional syntax when you have 4+ arguments to line up.
The_Fury said:
I will agree with you on the Nix* command line and man pages, they can be an absolute nightmare to the uninitiated and should be used as a lesson not to ever let programmers and tech types write help files for non tech types.
FWIW I'm not sure they were written for non-tech types.
07 Sep, 2008, Cratylus wrote in the 11th comment:
Samson said:
I really don't think it would help spur growth in muds to start turning their administration commands into engineering lessons in order for people to learn how to use them. It's very off-putting.
Tokens that modify a command's default behavior are not
especially advanced "engineering".
From DOS to VMS to Solaris, when managing complex
information at the command line, it's just a generally
accepted practice to have related functionality accessible
under one command with variable syntax based on tokens.
I don't think that such tokens are in command line oriented
OSes and clients because people are trying to make them
difficult to use. I think they are there because the
consensus is that they are useful and more helpful than
a-large-number-of-similar-commands, or commands whose
different functionality depends solely on the order of passed arguments.
What I personally would find offputting is if there
had to be four separate commands for "add a group", "remove
a group", "add a user to a group", "remove a user from
a group". I think that is far more taxing…but as you
seem to accept in your post, these are matters of
personal preference.
Just out of curiosity, if such tokens are undesirable, then
what would be a good way to handle the functionality in
the groupmod and people command examples I provided?
-Crat
http://lpmuds.net
08 Sep, 2008, David Haley wrote in the 12th comment:
Groupmod is simple enough where you could get away with things like 'group add person' or 'group remove person'. The token-style arguments simplify things when you have many possible flags, all (or most) of which are optional, and which furthermore take their own arguments.
Well, actually, the dash-style is just preference: it would be doing the exact same thing to 'expand' the dashes into their full meaning. I just think the dashes make it more clear that you are specifying a flag. Actually, I'm allowing long/short ways of specifying arguments, with a preference toward the long version for clarity; the short version is for convenience once you know what you're doing.
I feel like I started this post wanting to say something else but I got distracted and lost it, so, err, yeah. :rolleyes:
Well, actually, the dash-style is just preference: it would be doing the exact same thing to 'expand' the dashes into their full meaning. I just think the dashes make it more clear that you are specifying a flag. Actually, I'm allowing long/short ways of specifying arguments, with a preference toward the long version for clarity; the short version is for convenience once you know what you're doing.
I feel like I started this post wanting to say something else but I got distracted and lost it, so, err, yeah. :rolleyes:
08 Sep, 2008, Cratylus wrote in the 13th comment:
Quote
Groupmod is simple enough where you could get away with things like 'group add person' or 'group remove person'. The token-style arguments simplify things when you have many possible flags, all (or most) of which are optional, and which furthermore take their own arguments.
Ah! Well if what is being argued is "add" versus "-a"
then I agree that the form of the token is of
limited relevance. I was coming at it from "some token versus
none at all" angle. If the question is which of "add"
or "-a" is preferable, then we're already on the
same page that "tokens are good and useful". I really
wouldn't care much which convention my codebase used, so long
as it was consistent and untedious.
My apologies if my confusion muddied the topic.
Having said that, I'm pretty sure I'd get tired of
typing stuff like "people only admins sortby class"
rather than "people -ac"
Even "people –admins –sort=class" GNU style would
get old fast. For me.
Just a preference.
-Crat
http://lpmuds.net
08 Sep, 2008, David Haley wrote in the 14th comment:
No, no confusion at all. I fully agree that the short form is very nice. But the second example you gave is what shows the power of a token library, since you can parse very quickly what is going on rather than having to guess that "admins" is a token without an argument, but "sort" is. Let the token library do the parsing, and then be happy with the result map. (And yes, make it -a and -s instead too.)
The GNU style of long arguments come into play when you're just learning a command (oftentimes they are more intuitive), or if they've run out of sensible alphabet characters for options. I like them in those cases, but always use a short form if it's available and I know it – and if I do something often enough I usually go in and figure it out in the man page.
The GNU style of long arguments come into play when you're just learning a command (oftentimes they are more intuitive), or if they've run out of sensible alphabet characters for options. I like them in those cases, but always use a short form if it's available and I know it – and if I do something often enough I usually go in and figure it out in the man page.
Random Picks
I'm thinking that a way around this would be to have dash-style arguments to the command. For example,
This would list all issues with status 'open', and category 'idea'.
You could also do:
to get a list of issues assigned to Ksilyan.
Without dashes, you'd have to have either play all kinds of guessing games, or have different commands in the 'list' position.
With a function that parses these options, it would be pretty easy to just extract key/value pairs from the arguments and then figure out in the command what to do based on those key/value pairs. In the example above (of getting a list of issues) it becomes very easy to allow the specification (or not) of several search criteria.
Is this syntax fine, cumbersome, useful, useless, …?
EDIT: I cross-posted this to Nick Gammon's forums.