4 ms·

The only good ideas I saw in this post were shell-known argument semantics (perhaps via standardized --help output) and pipe inspection. The second idea is alre

by branden 17y ago

The only good ideas I saw in this post were shell-known argument semantics (perhaps via standardized --help output) and pipe inspection. The second idea is already available with the pv command. > What other things could we do to trick out the command line? The reason I use a command line is specifically because it's not tricked out.

TallGuyShort 17y ago
I agree - the more 'tricked out' it is, the more cpu it hogs. The computer I have now is practically a supercomputer compared to what I worked on 10 years ago, and yet my workflow is still interrupted when my system practically freezes so that it can switch to a different window. I would so much rather work in an ugly environment if I could just be in control of where my computing power gets spent.
swolchok 17y ago
bash-completion does the argument thing as well.
- zzkt 17y ago
  One of the points the article makes is not that it can be done (by whatever shell) but that any context dependent completion that happens with current shells needs to manually track details of each command to some degree.
philjackson 17y ago
I don't even buy the pipe inspection idea. We can already do it with tee, and to be honest I only ever use that because I need to persist the data mid-chain, rather than inspect it.
philh 17y ago
As he mentions, zsh also knows argument semantics. So does bash. He never explains how Bespin implements this feature, but I don't see how you can get a significant improvement on the way these shells do it (which he says is probably not the best way) without abandoning the standard toolchain altogether. (zsh uses scripts to do it, which can use --help output if desired. ISTR that they're rather complicated, but then they're also rather powerful. I think they become much simpler in degenerate cases, but I've only ever dabbled and that was over a year ago.) For the pipe inspection, I got the impression he might have been talking about "look at the data that's being sent". Which can be done with tee, but both that and pv require that you insert them into the chain beforehand. I think there's room for improvement there. (I suspect it's possible to do something with /proc/$$/fd, but I'm not sure and I wouldn't know how.) I do think shells and terminal emulators should interact better with each other. I often wish my rxvt knew about my GNU screen windows, so that the scrollbar and mouse wheel worked consistently and I could navigate tabs on the status bar by clicking on them.
bonaldi 17y ago
The reason I use a command line is specifically because it's not tricked out. That's valid, but the reason I use one is that it lets me get certain tasks done much faster than I can get them done with the gui. I don't think we've reached the pinnacle of the form, though -- I'd much rather we could expand the areas where it's the fastest way to get the job done. One weakness with the standard unix cli is in discoverability. The MPW environment for the original Mac had a great system for this -- option-enter on any command would bring up a gui with that allowed you to build up the options and flags. It was the perfect mix of GUI: invisible when you didn't need it, but vastly easier for the first use of an unfamiliar command. That said, I think the people who think like you are in the majority of CLI users, so innovations like these will struggle to get traction. Sucks to be me :)
- branden 17y ago
  I agree - the CLI's biggest weakness is discoverability, and the feature you describe is nice way to address it. And it's the right way to add a frill - there if you need it, invisible if you don't. Bespin's interface, on the other hand, is just obnoxious. It's great eye candy, but there's so much visual noise and wasted space that I could easily see it affecting productivity. I'll call it eye diabetes.
  - discojesus 17y ago
    eyeabetes? Or as Wilford Brimley might say, "eyeabeetus."
- plesn 17y ago
  I agree that the main weakness of the unix cli is in discoverability. This would require at least a limited standard interface (for declaring options and help) but it would not be enought for specific usages. So the overkill solution is real introspection abilities (from what I understood MS did this thanks to .net in its cli), but you loose simplicity and text everywhere.
- gaius 17y ago
  Every AIX admin has used SMIT in a similar way (tho' it is curses rather than a full GUI).
deleted 17y ago
[deleted]

by branden 17y ago

TallGuyShort 17y ago

I agree - the more 'tricked out' it is, the more cpu it hogs. The computer I have now is practically a supercomputer compared to what I worked on 10 years ago, and yet my workflow is still interrupted when my system practically freezes so that it can switch to a different window. I would so much rather work in an ugly environment if I could just be in control of where my computing power gets spent.

swolchok 17y ago

bash-completion does the argument thing as well.

zzkt 17y ago
One of the points the article makes is not that it can be done (by whatever shell) but that any context dependent completion that happens with current shells needs to manually track details of each command to some degree.

philjackson 17y ago

I don't even buy the pipe inspection idea. We can already do it with tee, and to be honest I only ever use that because I need to persist the data mid-chain, rather than inspect it.

philh 17y ago

As he mentions, zsh also knows argument semantics. So does bash. He never explains how Bespin implements this feature, but I don't see how you can get a significant improvement on the way these shells do it (which he says is probably not the best way) without abandoning the standard toolchain altogether. (zsh uses scripts to do it, which can use --help output if desired. ISTR that they're rather complicated, but then they're also rather powerful. I think they become much simpler in degenerate cases, but I've only ever dabbled and that was over a year ago.) For the pipe inspection, I got the impression he might have been talking about "look at the data that's being sent". Which can be done with tee, but both that and pv require that you insert them into the chain beforehand. I think there's room for improvement there. (I suspect it's possible to do something with /proc/$$/fd, but I'm not sure and I wouldn't know how.) I do think shells and terminal emulators should interact better with each other. I often wish my rxvt knew about my GNU screen windows, so that the scrollbar and mouse wheel worked consistently and I could navigate tabs on the status bar by clicking on them.

bonaldi 17y ago

The reason I use a command line is specifically because it's not tricked out. That's valid, but the reason I use one is that it lets me get certain tasks done much faster than I can get them done with the gui. I don't think we've reached the pinnacle of the form, though -- I'd much rather we could expand the areas where it's the fastest way to get the job done. One weakness with the standard unix cli is in discoverability. The MPW environment for the original Mac had a great system for this -- option-enter on any command would bring up a gui with that allowed you to build up the options and flags. It was the perfect mix of GUI: invisible when you didn't need it, but vastly easier for the first use of an unfamiliar command. That said, I think the people who think like you are in the majority of CLI users, so innovations like these will struggle to get traction. Sucks to be me :)

branden 17y ago
I agree - the CLI's biggest weakness is discoverability, and the feature you describe is nice way to address it. And it's the right way to add a frill - there if you need it, invisible if you don't. Bespin's interface, on the other hand, is just obnoxious. It's great eye candy, but there's so much visual noise and wasted space that I could easily see it affecting productivity. I'll call it eye diabetes.
- discojesus 17y ago
  eyeabetes? Or as Wilford Brimley might say, "eyeabeetus."
plesn 17y ago
I agree that the main weakness of the unix cli is in discoverability. This would require at least a limited standard interface (for declaring options and help) but it would not be enought for specific usages. So the overkill solution is real introspection abilities (from what I understood MS did this thanks to .net in its cli), but you loose simplicity and text everywhere.
gaius 17y ago
Every AIX admin has used SMIT in a similar way (tho' it is curses rather than a full GUI).

deleted 17y ago

[deleted]