16 ms·

Unix permits programs to communicate with one another, and with the user, exclusively through character streams. You can’t write a function that retur

Unix permits programs to communicate with one another, and with the user, exclusively through character streams. You can’t write a function that returns a list of files because the shell doesn’t know what a “list” is, doesn’t know what “files” are, and couldn’t tell you the difference between a “function” and a “program” if its life depended on it. Programs don’t “take arguments” and “return values”, they read characters from stdin and print characters to stdout! And this is why I consider PowerShell a more Unix-y shell than bash. Powershell commands don't just operate on character streams. They operate on CLR objects. For example, the PowerShell equivalent of grep, Select-String, doesn't return a string, or even a list of strings. It returns a list of match objects, which contain the regexp used, the matching string, and the file that matched. PowerShell often gets dinged for its verbosity, but honestly, I find it much easier to compose PowerShell commands because I know exactly what each command does, and the command-line flags are mostly intuitive. Meanwhile, Unix commands are shorter, yes, but it's a lot more difficult for me to remember, e.g. that if I want to run a command across a number of files, I have to pass the command to find.

jhbadger 10y ago
I remember VMS fans praising their proprietary ecosystem of commands. How's that working out for them?
- nailer 10y ago
  Powershell is Open Source. https://github.com/PowerShell/PowerShell/blob/master/LICENSE.txt https://github.com/PowerShell/PowerShell/blob/master/LICENSE...
- ksk 10y ago
  You only say that because SCO lost a lawsuit. UNIX was a closed source proprietary OS.
  - cestith 10y ago
    SCO lost a lawsuit because all claims brought in the suit were entirely baseless.
    - ksk 10y ago
      That literally has nothing to do with my point. UNIX was a closed source proprietary system, and so was VMS.
      - cestith 10y ago
        If you look at the commit history, the BSDs are very much derived from AT&T Unix.
        ksk 10y ago
        Sorry, I don't know what your point is. My initial comment was a response to the snarky "proprietary systems suck" comment, saying that UNIX itself was a proprietary design.
        cestith 10y ago
        The original tiny Version 1 through Version 6 system may have been more or less proprietary (although provided with source for comparatively little money) but the Unix ecosystem hasn't been proprietary for a very long time. Many of the commands people think of today came not from AT&T at all, but from Berkeley. Even as the commercial Unix platforms split, flourished, and fell apart keeping their own source more or less private Ultrix, Solaris, Irix, AIX, SCO, SunOS, OSF/1, HP/UX, Digital Unix, and others were more or less "Unix" with a few caveats about compatibility. POSIX and the SUS were formed. Systems got certified. Then the GNU tools were written and Linux became their kernel. Then, the Berkeley vs. AT&T lawsuit ended and we got the explosion of open source BSDs - NetBSD, OpenBSD, FreeBSD, Midnight BSD, DragonflyBSD... So yes, technically the original AT&T Unix was proprietary. That's not all there is to Unix nor has it been for decades. There is no Single VMS Specification. There are no independent systems certified as VMS compliant. You run what DEC / Compaq / HP / VMS Systems supplies and you like it or you don't. There is no Single Windows Specification. You take what Microsoft gives you or not. Unix is an open standard.
- linksnapzz 10y ago
  They're still using them, on a platform that's still supported && under development? Pity the poor VMS ppl. never having the pleasure of trying to figure out what "distro" with which kernel to run on their hardware.
nailer 10y ago
As a Linux user, who's worked for both Red Hat and IBM's Linux group: damn straight. Here's my posh profile: https://github.com/mikemaccana/powershell-profile/blob/master/Microsoft.PowerShell_profile.ps1 https://github.com/mikemaccana/powershell-profile/blob/maste...
jpk 10y ago
I find PowerShell a delight to script in, but terribly cumbersome to use interactively. The exact opposite is true for me when it comes to Unixy shells. I think part of the staying power (whether intentional or not) of composition via character streams is that in a text-based environment, humans also operate on character streams. We can structure things in machine memory as objects or lists or whatever, but when the information hits our meat cameras it's all just characters. When I run a command, the output I see is what I'll get when I pipe it somewhere. I feel like PowerShell is a step forward in the sense that it's a new thing with a more consistent design than the cobbled, creaky Unix environments we've become accustomed to. But at the same time I feel like it throws away one of the most intuitive aspects of the Unix interactive shells (character streams).
- m_mueller 10y ago
  Couldn't there be a middle ground where command and object member names have nice short aliases, but they work on and produce objects instead of character streams? I find it questionable that the productivity of the unix shell is due to it being stream-only - it could easily fall back to a stream (using each classes representation function) if you output it to a stream receiver, like the terminal itself or a text file.
  - derekp7 10y ago
    That's what I'd like to see, is to add a "--xml" or "--json" flags to any common command (such as ps, ls, grep, find, ...). And have appropriate handling in the shell for xml or json output.
    - emaste 10y ago
      Many FreeBSD utilities support a --libxo flag that produces structured output, although there isn't special handling in shells yet. % ls --libxo json {"__version": "1", "file-information": {"directory":[{"entry": [{"name":"bar"}, {"name":"foo"}]}]} } % ls --libxo xml <file-information __version="1"><directory><entry><name>bar</name></entry><entry><name>foo</name></entry></directory></file-information>
ploxiln 10y ago
"ls" is oriented for human viewing, not composition with other tools. It's admittedly bad at that. But there's "find", and there's the convention of separating filepaths with a null character. Because null cannot occur in a filename, this is an unambiguous list. Programs do "take arguments" (another unambiguous list of null-terminated strings, if you quote them). Like when you specify a command to find with "-exec", for it to run for each file. That's another fine way to do composition. Another example of composition by arguments is "sudo". It switches to root, then runs the arguments as a new process. Another example is ssh, it runs the arguments as on the remote server, and stdin and stdout still work. Check it out: tar -c testdir | ssh devbox sudo tar -C /opt -xv That created an archive from a local directory and wrote it to stdout, into ssh which ran sudo on the remote system, which ran tar, which changed to /opt and extracted an archive from stdin. None of those tools have special handling for each other, but they all work together. "Interesting" filenames in the archive are no problem here either.
- boomlinde 10y ago
  > "ls" is oriented for human viewing, not composition with other tools. Is there any basis for this claim? My understanding is that many of the GNU ls options are just shorthand for things that you'd traditionally do compositionally. It even reverts to a plain, more pipe-friendly style of output if its stdout is not a TTY. It still sucks at the job if you assume a system where the convention of not using newlines in filenames is ignored. Unix-likes are typically filled with these conventions that will qualify or disqualify any particular approach to a problem, which imposes a certain load on the users, administrators and developers that I assume isn't as severe in Powershell. An inexperienced user will constantly have to second-guess their solutions and may not experience any issues until much later, e.g. when it turns out that their script will have to accept spaces in filenames, or when their `rm -rf "/$INSTALLDIR"` needs to handle unset variables. I'm all cool with this since it offers brevity and a profound flexibility. If you want, you can implement typed, object-passing IPC like Powershell on top of Unix. If you don't, you may be content stream-editing and grepping in file listings to get what you want in the format you need. Besides that, the most compelling case against Powershell that I can thing of is that Windows programs typically aren't very composable. It's conventional for even the most mundane and simple tools to be operated using full-fledged GUIs, if only to offer a file selector and a run button.
milesrout 10y ago
That's completely orthogonal. GNU bash has nothing to do with what arguments you can pass to GNU ls. You could use bash to run notepad.exe just as you could use Powershell to run GNU ls. If that's not the case, if Powershell actually does integrate most of what are on Unix-like systems separate commands, then that's terrible. >Meanwhile, Unix commands are shorter, yes, but it's a lot more difficult for me to remember, e.g. that if I want to run a command across a number of files, I have to pass the command to find. You don't have to do anything of the sort. If you want to run things across a number of files, you need a list of those files, and you need to know what you want to run across them. That list of files can come from anywhere. Does it come from a text file? A script? Or find? Doesn't matter. If you do get them from find, you run things on them in precisely the same way you run things on any other list of files: a for loop. for file in $(find ...); do rm $file done Yeah you can also do find ... -exec rm {} \; or find ... -print0 | xargs -0 rm or any other number of other ways of doing it. But you don't have to. I'd probably use xargs to delete those files, honestly.
- BlackFingolfin 10y ago
  Of course one any of those filenames contains a space, your first two examples break down, and in the worst case result in the wrong files being deleted. Of course one can work around that, but in reality, this quickly gets difficult, and often is forgotten. The print0 works for some cases, but not in general (e.g. when one needs to do more complex processing)
  - leni536 10y ago
    The second example is fine, to be fair. {} is replaced by a single argument, no shell magic here.
  - milesrout 10y ago
    The second one doesn't fail, and the first one only fails because I wrote `rm $file` instead of `rm "$file"`, which I have done every single other time I've written the same thing this century.
kazinator 10y ago
What the PowerShell is trying to be is more of a Lisp descendant, something to which Unix has been mostly deaf. "Unixy" invokes very specific concepts; it is not a synonym for "computer sciency", "intellectually agreeable" or "non-sucky in some ways". (Relative to some things, it sometimes is these things, though!) Dumb character processing is "unixy", and Bash is in fact "dead unixy".
- uzoodoo 10y ago
  The "Unixy" approach is called "worse is better" https://dreamsongs.com/RiseOfWorseIsBetter.html https://dreamsongs.com/RiseOfWorseIsBetter.html
  - kazinator 10y ago
    Worse-is-better is rather a class of which unixy-approach is just one instance, or perhaps a derived class. There is all kinds of worse is better. A $20 Shimano-branded rear derailleur made in Indonesia on your bicycle is worse-is-better; nothing to do with Unix.
    - uzoodoo 10y ago
      Isn't that what I said? A funny cat picture posted all over the place is called a meme, but not all memes are cat pictures.
cestith 10y ago
Programs are passed arguments. As in, execve gives you a list of arguments that end up in argv and have absolutely no need to have anything to do with STDIN.
- dllthomas 10y ago
  Yeah, the input is actually a list of strings (arguments), a map of strings to strings (environment variables), and a string. (Assuming that we're not doing anything interesting with the file descriptors; I can see an argument for excluding that possibility from this discussion, but certainly it's a simplification.)
dllthomas 10y ago
I agree that being able to more easily give structure to data is probably an improvement, but I don't see why it's particularly "more Unix-y" - could you elaborate on what particular aspects of "Unix" or "Unix philosophy" you see it as better exemplifying?

jhbadger 10y ago

I remember VMS fans praising their proprietary ecosystem of commands. How's that working out for them?

nailer 10y ago
Powershell is Open Source. https://github.com/PowerShell/PowerShell/blob/master/LICENSE.txt https://github.com/PowerShell/PowerShell/blob/master/LICENSE...
ksk 10y ago
You only say that because SCO lost a lawsuit. UNIX was a closed source proprietary OS.
- cestith 10y ago
  SCO lost a lawsuit because all claims brought in the suit were entirely baseless.
  - ksk 10y ago
    That literally has nothing to do with my point. UNIX was a closed source proprietary system, and so was VMS.
    - cestith 10y ago
      If you look at the commit history, the BSDs are very much derived from AT&T Unix.
      - ksk 10y ago
        Sorry, I don't know what your point is. My initial comment was a response to the snarky "proprietary systems suck" comment, saying that UNIX itself was a proprietary design.
        cestith 10y ago
        The original tiny Version 1 through Version 6 system may have been more or less proprietary (although provided with source for comparatively little money) but the Unix ecosystem hasn't been proprietary for a very long time. Many of the commands people think of today came not from AT&T at all, but from Berkeley. Even as the commercial Unix platforms split, flourished, and fell apart keeping their own source more or less private Ultrix, Solaris, Irix, AIX, SCO, SunOS, OSF/1, HP/UX, Digital Unix, and others were more or less "Unix" with a few caveats about compatibility. POSIX and the SUS were formed. Systems got certified. Then the GNU tools were written and Linux became their kernel. Then, the Berkeley vs. AT&T lawsuit ended and we got the explosion of open source BSDs - NetBSD, OpenBSD, FreeBSD, Midnight BSD, DragonflyBSD... So yes, technically the original AT&T Unix was proprietary. That's not all there is to Unix nor has it been for decades. There is no Single VMS Specification. There are no independent systems certified as VMS compliant. You run what DEC / Compaq / HP / VMS Systems supplies and you like it or you don't. There is no Single Windows Specification. You take what Microsoft gives you or not. Unix is an open standard.
linksnapzz 10y ago
They're still using them, on a platform that's still supported && under development? Pity the poor VMS ppl. never having the pleasure of trying to figure out what "distro" with which kernel to run on their hardware.

nailer 10y ago

As a Linux user, who's worked for both Red Hat and IBM's Linux group: damn straight. Here's my posh profile: https://github.com/mikemaccana/powershell-profile/blob/master/Microsoft.PowerShell_profile.ps1 https://github.com/mikemaccana/powershell-profile/blob/maste...

jpk 10y ago

I find PowerShell a delight to script in, but terribly cumbersome to use interactively. The exact opposite is true for me when it comes to Unixy shells. I think part of the staying power (whether intentional or not) of composition via character streams is that in a text-based environment, humans also operate on character streams. We can structure things in machine memory as objects or lists or whatever, but when the information hits our meat cameras it's all just characters. When I run a command, the output I see is what I'll get when I pipe it somewhere. I feel like PowerShell is a step forward in the sense that it's a new thing with a more consistent design than the cobbled, creaky Unix environments we've become accustomed to. But at the same time I feel like it throws away one of the most intuitive aspects of the Unix interactive shells (character streams).

m_mueller 10y ago
Couldn't there be a middle ground where command and object member names have nice short aliases, but they work on and produce objects instead of character streams? I find it questionable that the productivity of the unix shell is due to it being stream-only - it could easily fall back to a stream (using each classes representation function) if you output it to a stream receiver, like the terminal itself or a text file.
- derekp7 10y ago
  That's what I'd like to see, is to add a "--xml" or "--json" flags to any common command (such as ps, ls, grep, find, ...). And have appropriate handling in the shell for xml or json output.
  - emaste 10y ago
    Many FreeBSD utilities support a --libxo flag that produces structured output, although there isn't special handling in shells yet. % ls --libxo json {"__version": "1", "file-information": {"directory":[{"entry": [{"name":"bar"}, {"name":"foo"}]}]} } % ls --libxo xml <file-information __version="1"><directory><entry><name>bar</name></entry><entry><name>foo</name></entry></directory></file-information>

ploxiln 10y ago

"ls" is oriented for human viewing, not composition with other tools. It's admittedly bad at that. But there's "find", and there's the convention of separating filepaths with a null character. Because null cannot occur in a filename, this is an unambiguous list. Programs do "take arguments" (another unambiguous list of null-terminated strings, if you quote them). Like when you specify a command to find with "-exec", for it to run for each file. That's another fine way to do composition. Another example of composition by arguments is "sudo". It switches to root, then runs the arguments as a new process. Another example is ssh, it runs the arguments as on the remote server, and stdin and stdout still work. Check it out: tar -c testdir | ssh devbox sudo tar -C /opt -xv That created an archive from a local directory and wrote it to stdout, into ssh which ran sudo on the remote system, which ran tar, which changed to /opt and extracted an archive from stdin. None of those tools have special handling for each other, but they all work together. "Interesting" filenames in the archive are no problem here either.

boomlinde 10y ago
> "ls" is oriented for human viewing, not composition with other tools. Is there any basis for this claim? My understanding is that many of the GNU ls options are just shorthand for things that you'd traditionally do compositionally. It even reverts to a plain, more pipe-friendly style of output if its stdout is not a TTY. It still sucks at the job if you assume a system where the convention of not using newlines in filenames is ignored. Unix-likes are typically filled with these conventions that will qualify or disqualify any particular approach to a problem, which imposes a certain load on the users, administrators and developers that I assume isn't as severe in Powershell. An inexperienced user will constantly have to second-guess their solutions and may not experience any issues until much later, e.g. when it turns out that their script will have to accept spaces in filenames, or when their `rm -rf "/$INSTALLDIR"` needs to handle unset variables. I'm all cool with this since it offers brevity and a profound flexibility. If you want, you can implement typed, object-passing IPC like Powershell on top of Unix. If you don't, you may be content stream-editing and grepping in file listings to get what you want in the format you need. Besides that, the most compelling case against Powershell that I can thing of is that Windows programs typically aren't very composable. It's conventional for even the most mundane and simple tools to be operated using full-fledged GUIs, if only to offer a file selector and a run button.

milesrout 10y ago

That's completely orthogonal. GNU bash has nothing to do with what arguments you can pass to GNU ls. You could use bash to run notepad.exe just as you could use Powershell to run GNU ls. If that's not the case, if Powershell actually does integrate most of what are on Unix-like systems separate commands, then that's terrible. >Meanwhile, Unix commands are shorter, yes, but it's a lot more difficult for me to remember, e.g. that if I want to run a command across a number of files, I have to pass the command to find. You don't have to do anything of the sort. If you want to run things across a number of files, you need a list of those files, and you need to know what you want to run across them. That list of files can come from anywhere. Does it come from a text file? A script? Or find? Doesn't matter. If you do get them from find, you run things on them in precisely the same way you run things on any other list of files: a for loop. for file in $(find ...); do rm $file done Yeah you can also do find ... -exec rm {} \; or find ... -print0 | xargs -0 rm or any other number of other ways of doing it. But you don't have to. I'd probably use xargs to delete those files, honestly.

BlackFingolfin 10y ago
Of course one any of those filenames contains a space, your first two examples break down, and in the worst case result in the wrong files being deleted. Of course one can work around that, but in reality, this quickly gets difficult, and often is forgotten. The print0 works for some cases, but not in general (e.g. when one needs to do more complex processing)
- leni536 10y ago
  The second example is fine, to be fair. {} is replaced by a single argument, no shell magic here.
- milesrout 10y ago
  The second one doesn't fail, and the first one only fails because I wrote `rm $file` instead of `rm "$file"`, which I have done every single other time I've written the same thing this century.

kazinator 10y ago

What the PowerShell is trying to be is more of a Lisp descendant, something to which Unix has been mostly deaf. "Unixy" invokes very specific concepts; it is not a synonym for "computer sciency", "intellectually agreeable" or "non-sucky in some ways". (Relative to some things, it sometimes is these things, though!) Dumb character processing is "unixy", and Bash is in fact "dead unixy".

uzoodoo 10y ago
The "Unixy" approach is called "worse is better" https://dreamsongs.com/RiseOfWorseIsBetter.html https://dreamsongs.com/RiseOfWorseIsBetter.html
- kazinator 10y ago
  Worse-is-better is rather a class of which unixy-approach is just one instance, or perhaps a derived class. There is all kinds of worse is better. A $20 Shimano-branded rear derailleur made in Indonesia on your bicycle is worse-is-better; nothing to do with Unix.
  - uzoodoo 10y ago
    Isn't that what I said? A funny cat picture posted all over the place is called a meme, but not all memes are cat pictures.

cestith 10y ago

Programs are passed arguments. As in, execve gives you a list of arguments that end up in argv and have absolutely no need to have anything to do with STDIN.

dllthomas 10y ago
Yeah, the input is actually a list of strings (arguments), a map of strings to strings (environment variables), and a string. (Assuming that we're not doing anything interesting with the file descriptors; I can see an argument for excluding that possibility from this discussion, but certainly it's a simplification.)

dllthomas 10y ago

I agree that being able to more easily give structure to data is probably an improvement, but I don't see why it's particularly "more Unix-y" - could you elaborate on what particular aspects of "Unix" or "Unix philosophy" you see it as better exemplifying?