An Idea for Combining Commands: ${...} rather than pipes
Today I was talking with Michael Pacchioli about the syntax for combining commands. I'm leaning toward using ${...} (I can't remember who suggested it to me a few weeks back).
Something like:
Sean O'Hagan is doing some great work on a parser.php script that I would like to use for the parse command.
Something like:
gim ${parse ${gnews royal wedding}}Well, it will unfortunately be uglier than that (especially the parse command), but that's the idea. Basically using a command called "parse" to extract a short snippet of text to pass to the outer command as a parameter.
Sean O'Hagan is doing some great work on a parser.php script that I would like to use for the parse command.
posted by Jonathan at 7/10/2005 06:38:00 p.m.
16 Comments:
Why not just use parentheses? "gim (parse (gnews royal wedding))"
Do you have a way to reserve the "parse" command so that no one else uses it before you figure out the implementation?
Jeremy - Hm! Parentheses are simpler, aren't they. Hopefully people don't use parentheses in their queries (I suspect they usually don't).
Sage - Good idea about reserving the command. I have reserved it.
Are pipes "|" really dying? What's the hurdle?
Sean - I was just thinking ${...} would allow us to do multiple parameters.
For example, compare:
gnews royal wedding | parse | gloc -what
to:
gloc -what ${parse ${gnews royal wedding}} -where ${parse ${g top tourist destinations}}
Perhaps both types of syntax could be allowed. There may be some commands where a simple "|" might be more natural (eg. random | fspell). However, you're quite right in saying that multiple parameters require a different syntax. I think ${...} had been suggested for creating new commands using other commands as input, in line with existing syntax at the time.
What about something like:
gloc -what {gnews blah1 | parse} -where {g blah2 | parse}
(the Unix awk command uses {}'s to enclose snippets of code.)
Just my 2 cents...
Sean - Also I know now who to credit with the ${...} idea: you!
I'm grateful for the information about how awk has {} instead of ${}. That's also closer to Jeremy's suggestion of using (). So yeah, let's go with {}.
So | is just a kind of shortcut for {}? Like, we won't be piping big chunks of HTML -- just simple little strings, right?
'cause I think passing simple strings between commands (rather than big chunks of HTML) might be all the power we need for the web command line. Sometimes simple is best.
If someone needs to pass a lot of data, they could simply pass the URL to it.
How is 'parse' going to work? I've just been working on processing the ls pages, and even with something that simple there's a lot of stuff that has to be stripped out before you're left with the information you want. I don't see how a single command with no parameters is going to be able to extract the exact information needed by the calling command, especially since different callers are going to be looking for different things.
Commands don't usually accept raw HTML in their parameters. A really nice core command would be 'url', that takes the name and parameters of another command and returns the resulting URL as a string rather than retrieving the page.
E.g "tiny {url apoddate 050605}" should work.
A few comments:
Personally I say why go with the redundancy of pipes if {} works fine? Just for the comfort of unix syntax? IMHO you should pick one or the other.
What about commands that would do jazzy things like export google search results, neatly formatted, to a text document (or word file)? Have such things been discussed yet?
What would be required for YubNub to be able to circumvent login screens? i.e. i could supply a uid and pwd on the commandline... That could be cool.
Also, assume some export command, as mentioned above did exist, and I wanted to email the resultant file to a friend. I might use a service like www.yousendit.com... but I'm not certain if yubnub could get around the javascript that appears to be making that page work? Ideas?
Look at the (not terribly useful) command:
random | fspell
I'm not sure how to write this using {}'s. So I think some kind of piping syntax is required, whether it be "|" or some other symbol. If this is true, then we do have two ways to write more complex commands, as in Jeremy's example:
tiny {url {apoddate 050605}}
apoddate 050605 | url | tiny
It could be up to the individual user which to use. Personally, I prefer the lower option because it seems cleaner, but it also might seem backwards to some users.
random 100 | fspell
fspell {random 100}
In my example, you don't want apoddate 050605 to execute. So I really did mean it like this:
url apoddate 050605 | tiny
tiny {url apoddate 050605}
(Note that there is no actual url command, and only Jonathan could add it.)
Yup, Jeremy's "url" command is going to be key.
I like Sean's idea of having two ways to say it: | or {}.
| is cleaner, but {} is more flexible.
Sean O'Hagan argues that {} should be used since awk uses {} to enclose snippets of code.
I would like to point out that math uses () to enclose things, and there are a lot more people out there who know math than know awk. More to the point, we're already using ${} for parameters in commands, and I think using () and ${} together will be less confusing than using {} and ${} together.
()'s are fine, unless there's a possibility that they conflict with arguments of a yubnub command (will people ever use ()'s as arguments?) or with the syntax of possible future yubnub functions, ie. some_yn_function().
I think {}'s are less frequently used in general, and therefore might cause fewer command-parsing problems.
However, I really don't care which is adopted. It's easier for me to type ()'s, but if it makes life difficult on the development side...
2c
Hmm ... I too am worried about () being used by some commands e.g. foo (a AND b) OR c ...
() would be quite natural, on the other hand, if we could use it (and Lisp-like ... but I digress).
So we have some choices: (), {}, $(), #{}. I'm leaning toward {}.
Mat - I like your idea about combining an "export to Word doc" command and a "yousendit" command...
Anything is possible. As a last resort, one could make a command to send these complex instructions to some uberserver to do the heavy lifting.
Post a Comment
<< Home