6 ms·

> You can tab complete variable names, cmdlet names, cmdlet switches, etc. UNIX shells can do all that too. > Additionally, by piping objects instead of text,

> You can tab complete variable names, cmdlet names, cmdlet switches, etc. UNIX shells can do all that too. > Additionally, by piping objects instead of text, you aren't caught off guard by things like spaces in a path name. Not just spaces, to be fair. Files that begin with a hyphen can cause major issues too. There’s definitely a lot of weird edge cases with UNIX shells but on the whole I still find them easier to work with than Powershell. But that’s just me

twothumbsup 8y ago
Which one did you learn to use first? Wondering if that has much of an impact. I've only used Powershell for a bit while I work with *nix shells daily so I'm definitely biased towards them but wonder if I'd cut my teeth on Powershell if I'd think the same way.
- laumars 8y ago
  Neither. I leaned the CLI from DOS (or it might have been CP/M?). Unless you count BBC BASIC?
pjmlp 8y ago
What about UNIX shells that allow to call public functions in dynamic libraries as if they were shell commands? Or interact with running applications using the OS APIs like Powershell allows with WMI, COM, OLE Automation and .NET? Yes, there is DBUS, but isn't really integrated across the whole stack.
- laumars 8y ago
  If I want that level of control I wouldn’t want to be writing a shell script in the first place. That’s the problem with Powershell for me, it’s taken the REPL concept but made it too feature rich and too verbose so you lose the speed of writing the code and simplicity of piping predictable streams of data. The thing with Linux / UNIX is it’s very command line driven from the outset. So if you wanted to do the function calls from shared libraries et al you could write a wrapper in C, Python, Perl, whatever and still use Bash etc to interface with it. You’re not tied to using Bash to solve all of your problems. Bash just provides a convenient interface for chaining all those tools in other languages together. Now I know the same can be said for command prompts on Windows but for whatever reason that seems to be less common than it is on POSIX.
  - pjmlp 8y ago
    That is where you get it wrong, because the REPL concept as introduced by Smalltalk and Interlisp-D/Lisp Machines it is exactly what Powershell tries to achieve. UNIX shells are a poor imitation of it.
    - laumars 8y ago
      I never said UNIX invented the REPL concept (though I’d have thought time sharing systems predated LISP machines) and this a conversation about personal preference so there is not right or wrong answers (aside arrogant comments from techies who feel they should belittle others for having differing preferences). I don’t happen to like Powershell. That doesn’t make me wrong. That literally just means I don’t happen to like Powershell. Period. (and voting me down for personal preference is really just pathetic)
      - pjmlp 8y ago
        I am not the one downvoting you, I rather have discussions, even when I might not be right.
    - lispm 8y ago
      > REPL concept the interactive REPL was introduced by Lisp around 1962 way before Lisp Machines, Smalltalk...
      - pjmlp 8y ago
        Yes, but not with the capabilities that their graphical sucessors brought into the computing world. You surely could not display inline structured data and interact with it graphically on an IBM 704 teletype.
        lispm 8y ago
        Well, you had Lisp structure editors already in the 60s. Doing it graphically doesn't really add too much to it. If you read the manual for BBN Lisp, you can see that it did end 60s / early 70s more than many current systems do - like managing source code, working with images, structure editors for code and data, sophisticated user-level error handling, etc..
- vasilia 8y ago
  > What about UNIX shells that allow to call public functions in dynamic libraries as if they were shell commands? dlcall > Or interact with running applications using the OS APIs like Powershell allows with WMI, COM, OLE Automation and .NET? Depends what you need. You can use nc -U /var/run/socket or pipes with expect. If you have root permissions you can use gdb scripting/ebpf to communicate with user-space/kernel-space data of your application. > Yes, there is DBUS, but isn't really integrated across the whole stack. DBUS is a bus for desktops/mobile. I never saw that someone use it for server applications. The main idea(after KISS) of the Linux shell is that if you can't write something in awk it will be better to use python. Actually, in the Linux world, GRPC/REST is more common than OS-level API.
  - pjmlp 8y ago
    So a couple of Linuxisms not portable across UNIX, which was my point.
    - laumars 8y ago
      Nope. Your point was to argue personal preference as fact rather than simply accepting that some people like apples and others prefer oranges. I get so utterly sick of stupid arguments where people compare their tools and then proceed to makes claims that one is objectively better than another when it’s clearly just a matter of personal taste
    - vasilia 8y ago
      Unix sockets and pipes are portable across all Unix(POSIX, because Linux is not Unix, but OS X is). Furthermore Unix sockets and pipes backwards compatible to 4.4BSD Unix or older OS. Actually, this comparison is not correct. Windows and Unix have a different philosophy of kernel<->user level interaction. While Windows tries to add all functionality to the kernel, Unix does this on user level. Remember the KISS principle. So If you comfortable with Windows OS level API it's good for you, but for Unix world, it's not necessary to do something because we already have a different inter-process communication approach.
      - 8y ago

twothumbsup 8y ago

Which one did you learn to use first? Wondering if that has much of an impact. I've only used Powershell for a bit while I work with *nix shells daily so I'm definitely biased towards them but wonder if I'd cut my teeth on Powershell if I'd think the same way.

laumars 8y ago
Neither. I leaned the CLI from DOS (or it might have been CP/M?). Unless you count BBC BASIC?

pjmlp 8y ago

What about UNIX shells that allow to call public functions in dynamic libraries as if they were shell commands? Or interact with running applications using the OS APIs like Powershell allows with WMI, COM, OLE Automation and .NET? Yes, there is DBUS, but isn't really integrated across the whole stack.

laumars 8y ago
If I want that level of control I wouldn’t want to be writing a shell script in the first place. That’s the problem with Powershell for me, it’s taken the REPL concept but made it too feature rich and too verbose so you lose the speed of writing the code and simplicity of piping predictable streams of data. The thing with Linux / UNIX is it’s very command line driven from the outset. So if you wanted to do the function calls from shared libraries et al you could write a wrapper in C, Python, Perl, whatever and still use Bash etc to interface with it. You’re not tied to using Bash to solve all of your problems. Bash just provides a convenient interface for chaining all those tools in other languages together. Now I know the same can be said for command prompts on Windows but for whatever reason that seems to be less common than it is on POSIX.
- pjmlp 8y ago
  That is where you get it wrong, because the REPL concept as introduced by Smalltalk and Interlisp-D/Lisp Machines it is exactly what Powershell tries to achieve. UNIX shells are a poor imitation of it.
  - laumars 8y ago
    I never said UNIX invented the REPL concept (though I’d have thought time sharing systems predated LISP machines) and this a conversation about personal preference so there is not right or wrong answers (aside arrogant comments from techies who feel they should belittle others for having differing preferences). I don’t happen to like Powershell. That doesn’t make me wrong. That literally just means I don’t happen to like Powershell. Period. (and voting me down for personal preference is really just pathetic)
    - pjmlp 8y ago
      I am not the one downvoting you, I rather have discussions, even when I might not be right.
  - lispm 8y ago
    > REPL concept the interactive REPL was introduced by Lisp around 1962 way before Lisp Machines, Smalltalk...
    - pjmlp 8y ago
      Yes, but not with the capabilities that their graphical sucessors brought into the computing world. You surely could not display inline structured data and interact with it graphically on an IBM 704 teletype.
      - lispm 8y ago
        Well, you had Lisp structure editors already in the 60s. Doing it graphically doesn't really add too much to it. If you read the manual for BBN Lisp, you can see that it did end 60s / early 70s more than many current systems do - like managing source code, working with images, structure editors for code and data, sophisticated user-level error handling, etc..
vasilia 8y ago
> What about UNIX shells that allow to call public functions in dynamic libraries as if they were shell commands? dlcall > Or interact with running applications using the OS APIs like Powershell allows with WMI, COM, OLE Automation and .NET? Depends what you need. You can use nc -U /var/run/socket or pipes with expect. If you have root permissions you can use gdb scripting/ebpf to communicate with user-space/kernel-space data of your application. > Yes, there is DBUS, but isn't really integrated across the whole stack. DBUS is a bus for desktops/mobile. I never saw that someone use it for server applications. The main idea(after KISS) of the Linux shell is that if you can't write something in awk it will be better to use python. Actually, in the Linux world, GRPC/REST is more common than OS-level API.
- pjmlp 8y ago
  So a couple of Linuxisms not portable across UNIX, which was my point.
  - laumars 8y ago
    Nope. Your point was to argue personal preference as fact rather than simply accepting that some people like apples and others prefer oranges. I get so utterly sick of stupid arguments where people compare their tools and then proceed to makes claims that one is objectively better than another when it’s clearly just a matter of personal taste
  - vasilia 8y ago
    Unix sockets and pipes are portable across all Unix(POSIX, because Linux is not Unix, but OS X is). Furthermore Unix sockets and pipes backwards compatible to 4.4BSD Unix or older OS. Actually, this comparison is not correct. Windows and Unix have a different philosophy of kernel<->user level interaction. While Windows tries to add all functionality to the kernel, Unix does this on user level. Remember the KISS principle. So If you comfortable with Windows OS level API it's good for you, but for Unix world, it's not necessary to do something because we already have a different inter-process communication approach.
    - 8y ago