3 ms·

> They're not that bad (GNU coreutils is generally pretty good) and you usually remember the edge cases fairly quickly (eg `dd`). Sadly you get inconsistencies

by lispm 11y ago

> They're not that bad (GNU coreutils is generally pretty good) and you usually remember the edge cases fairly quickly (eg `dd`). Sadly you get inconsistencies in all coding frameworks, whether it's semantic, function names in the core libraries or whatever. Generally this is all awful and low-level. Just see the UI interface difference between 'dd' and 'Copy File' on a Lisp Machine. The UI is worlds away. > UNIX shells do have a lot of hidden gotchya's which can make life "interesting" (read: "oh fuck oh fuck oh fuck" lol). But the power of being able to use reusable blocks of any language through pipelining (and to a lesser extent, exit codes) is genius. It means one can mix and match LISP, Java, Perl, Python, C++, Go all inside one shell script. You can do that on a Lisp Machine, too. With the difference that no pipelining of text is necessary. Just reuse the objects. The data is all fully object-oriented and self identifying. Note that I'm using Unix and other OS variants since the 80s and I'm fully aware of command line UIs from VMS, SUN OS, Cisco, IBM AIX, OSX, GNU, Plan9, Oberon OS, and various others. > I do understand the hate towards UNIX shells. It's not hate. Most Unix shells are just fully dumb. Many people like to use primitive text based UIs with lots of corner cases, which makes them look intelligent for remembering obscure commands, obscure options without real UI help. Take cp. The shell does not know the various options the command takes. The shell does not know what the types and the syntax of the options is. The shell does not know which options can be combined and which not. It can't prompt for shell options. It can't check the command syntax before calling it. It can't provide any help when the syntax is wrong. It can't deal with errors during command execution. There is no in-context help. It can't reusing prior commands other that just editing them on a textual base. The output of the command is just text and not structured data. There are really really zillions of problems. There have been attempts to address this putting different user interfaces on top. For example IBM provided an extensive menu based administration tool for AIX. > But no tool is perfect and pragmatically I've found shells to be far more productive than anything I've ever attempted to replace it with. Which is the real crux of why we use these tools. But like anything in IT, this is just my personal preference. Your mileage may vary. Many people have found shell productive. That's why there is a zillion of different shells. You can even use Lisp-based shells like scsh and esh (http://www.serpentine.com/blog/2007/02/16/esh-the-fabulous-forgotten-scheme-implementation/ http://www.serpentine.com/blog/2007/02/16/esh-the-fabulous-f...) or GNU Emacs. But for most part all these attempts stay in that little box and don't escape the general problems.

laumars 11y ago
I suspect your argument is now more about personal preference than anything. So I'll just address a few specific points you've raise: > Generally this is all awful and low-level. Just see the UI interface difference between 'dd' and 'Copy File' on a Lisp Machine. The UI is worlds away. Well yeah, I did already example `dd` as an inconsistency. :) > You can do that on a Lisp Machine, too. With the difference that no pipelining of text is necessary. Just reuse the objects. The data is all fully object-oriented and self identifying. Indeed you can. As you can also with DOS, Powershell and so forth. I wasn't suggesting that UNIX shells were unique (though I can see how it might read that way), but that it was UNIX shells which pioneered that concept. For all their faults and the technology that might have superseded it: the idea of pipelining reusable blocks of code was a genius idea for its era. Powershell also supports passing objects like Lisp does. Personally I prefer the dumb approach; however in all other aspects of programming I do prefer strongly typed languages. This is just personal preference. > The shell does not know the various options the command takes. The shell does not know what the types and the syntax of the options is. The shell does not know which options can be combined and which not. It can't prompt for shell options. It can't check the command syntax before calling it. It can't provide any help when the syntax is wrong. It can't deal with errors during command execution. There is no in-context help. It can't reusing prior commands other that just editing them on a textual base. The output of the command is just text and not structured data. There are really really zillions of problems. This part isn't accurate. The original Bourne shell cannot but bash, zsh and fish can all do all of the above. Albeit sometimes (particularly with Bash) you need to install additional helper routines that aren't always shipped / configured with the default package. I believe csh also supports most if not all of the above too. I'm sure lisp does it better, but I was never arguing that UNIX shells are better Lisp to begin with. Just that I believe Bash et al to have a lower barrier of entry than Lisp. I think on that specific point we might have to agree to disagree - but I don't see many non-programmers using Lisp and this is why I think Bash has a lower barrier of entry (to go back to my original point). I can completely understand and relate to why you enjoy working inside a Lisp REPL shell though.
- lispm 11y ago
  > I'm sure lisp does it better Lisp does nothing. It is a programming language. > Just that I believe Bash et al to have a lower barrier of entry than Lisp I doubt that, given how horrible Bash as a language and as a shell is. There is no reason why there can't be more sane command systems and better shell languages. See the zsh documentation on completion: http://zsh.sourceforge.net/Guide/zshguide06.html http://zsh.sourceforge.net/Guide/zshguide06.html This is all totally over the head of the average user. _perforce_revisions() { local rline match mbegin mend pfx local -a rl pfx=${${(Q)PREFIX}%%\#*} compset -P '*\#' # Numerical revision numbers, possibly with text. if [[ -z $PREFIX || $PREFIX = <-> ]]; then # always allowed (same as none) rl=($rl 0) _call_program filelog p4 filelog \$pfx 2>/dev/null | while read rline; do if [[ $rline = (#b)'... #'(<->)*\'(*)\' ]]; then rl=($l "${match[1]}:${match[2]}") fi done fi # Non-numerical (special) revision names. if [[ -z $PREFIX || $PREFIX != <-> ]]; then rl=($rl 'head:head revision' 'none:empty revision' 'have:current synced revision') fi _describe -t revisions 'revision' rl } Tell me that this piece of code has a 'low barrier of entry' or even a 'lower barrier of entry'. It's just that a generation of experts has been self selected to find that usable. > but I was never arguing that UNIX shells are better Lisp to begin with I was not talking about Lisp. I was talking about software. One could write much better command shells in C than what Unix shells offers. I understand that certain people find Unix like shells attractive. From a general user interface perspective they are horrible.

by lispm 11y ago

laumars 11y ago

I suspect your argument is now more about personal preference than anything. So I'll just address a few specific points you've raise: > Generally this is all awful and low-level. Just see the UI interface difference between 'dd' and 'Copy File' on a Lisp Machine. The UI is worlds away. Well yeah, I did already example `dd` as an inconsistency. :) > You can do that on a Lisp Machine, too. With the difference that no pipelining of text is necessary. Just reuse the objects. The data is all fully object-oriented and self identifying. Indeed you can. As you can also with DOS, Powershell and so forth. I wasn't suggesting that UNIX shells were unique (though I can see how it might read that way), but that it was UNIX shells which pioneered that concept. For all their faults and the technology that might have superseded it: the idea of pipelining reusable blocks of code was a genius idea for its era. Powershell also supports passing objects like Lisp does. Personally I prefer the dumb approach; however in all other aspects of programming I do prefer strongly typed languages. This is just personal preference. > The shell does not know the various options the command takes. The shell does not know what the types and the syntax of the options is. The shell does not know which options can be combined and which not. It can't prompt for shell options. It can't check the command syntax before calling it. It can't provide any help when the syntax is wrong. It can't deal with errors during command execution. There is no in-context help. It can't reusing prior commands other that just editing them on a textual base. The output of the command is just text and not structured data. There are really really zillions of problems. This part isn't accurate. The original Bourne shell cannot but bash, zsh and fish can all do all of the above. Albeit sometimes (particularly with Bash) you need to install additional helper routines that aren't always shipped / configured with the default package. I believe csh also supports most if not all of the above too. I'm sure lisp does it better, but I was never arguing that UNIX shells are better Lisp to begin with. Just that I believe Bash et al to have a lower barrier of entry than Lisp. I think on that specific point we might have to agree to disagree - but I don't see many non-programmers using Lisp and this is why I think Bash has a lower barrier of entry (to go back to my original point). I can completely understand and relate to why you enjoy working inside a Lisp REPL shell though.

lispm 11y ago
> I'm sure lisp does it better Lisp does nothing. It is a programming language. > Just that I believe Bash et al to have a lower barrier of entry than Lisp I doubt that, given how horrible Bash as a language and as a shell is. There is no reason why there can't be more sane command systems and better shell languages. See the zsh documentation on completion: http://zsh.sourceforge.net/Guide/zshguide06.html http://zsh.sourceforge.net/Guide/zshguide06.html This is all totally over the head of the average user. _perforce_revisions() { local rline match mbegin mend pfx local -a rl pfx=${${(Q)PREFIX}%%\#*} compset -P '*\#' # Numerical revision numbers, possibly with text. if [[ -z $PREFIX || $PREFIX = <-> ]]; then # always allowed (same as none) rl=($rl 0) _call_program filelog p4 filelog \$pfx 2>/dev/null | while read rline; do if [[ $rline = (#b)'... #'(<->)*\'(*)\' ]]; then rl=($l "${match[1]}:${match[2]}") fi done fi # Non-numerical (special) revision names. if [[ -z $PREFIX || $PREFIX != <-> ]]; then rl=($rl 'head:head revision' 'none:empty revision' 'have:current synced revision') fi _describe -t revisions 'revision' rl } Tell me that this piece of code has a 'low barrier of entry' or even a 'lower barrier of entry'. It's just that a generation of experts has been self selected to find that usable. > but I was never arguing that UNIX shells are better Lisp to begin with I was not talking about Lisp. I was talking about software. One could write much better command shells in C than what Unix shells offers. I understand that certain people find Unix like shells attractive. From a general user interface perspective they are horrible.