10 ms·

You should try powershell. It's actually pretty good and is much better than unix shells.

KnightHawk3 11y ago
It's petty but I can't get over the case sensitive command names with capital letters in it. They are honestly too long.
- oblio 11y ago
  It has aliases for 90% of those commands, though.
- AndrewGaspar 11y ago
  PowerShell is not case sensitive.
vezzy-fnord 11y ago
It might be better than Bourne or C-derived shells, but I have a hard time conceding it beats for instance Inferno shell, es or rc.
- kbenson 11y ago
  I know enough and have had enough tangential contact with PowerShell to know that it works on a fundamentally different paradigm, as it does not pipe text, but objects. As such, it's hard to say it's "better" since it's so different. I would hazard that it's better some respects for some things, and the reverse is true as well. It fits well into windows, but would not fit well into UNIX systems, where most things are already just text. I haven't used inforno-shell, es or rc, so can't comment on them directly. That said, if they are easily comparable to bash, ksh, etc, then you probably owe it to yourself to see what powershell is about and why it's fundamentally different.
  - vezzy-fnord 11y ago
    That said, if they are easily comparable to bash, ksh, etc I specifically contrasted them against Bourne or C-like shells, so I thought that much was clear that they are not. I have tried PowerShell. I think this comment summarizes it well: https://lobste.rs/s/vzjalp/why_i_dislike_systemd/comments/sh8yvt#c_sh8yvt https://lobste.rs/s/vzjalp/why_i_dislike_systemd/comments/sh...
    - moron4hire 11y ago
      That's because shells on Windows aren't management tools. That role is filled by Group Policy.
    - useerup 11y ago
      That comment is utterly uninformed. If you want to run a script simultaneously on a number of hosts, you use the Invoke-Command cmdlet (or it's alias icm). If you want to stop a process, you use Stop-Process (or it's alias kill). To copy files or directories you use the Copy-Item cmdlet (or one of it's aliases cp and copy). Hence, to stop WINWORD on a host1, host2 and host3 and then copy a directory from host0 to each of them, you would write: icm host1,host2,host3 {kill -name WINWORD; cp \\host0\C$\source C:\dest } As simple as it should be! The commenter is correct that you cannot start an application in another session from remote. However, this is a security restriction that prevents cross-session contamination and shatter attacks. It is a (security) limitation of Windows, not of PowerShell. Under Windows, all services run in session 0, the interactive user run in session 1, and if more users log on (e.g. remotely through PowerShell) they are each created in their own session. Windows put severe restrictions on what programs can do cross-session - even if the processes run under the same user account: They cannot send messages, interact with the desktop windows, inject code, start threads etc. The commenter also alludes to other security settings that you'll encounter when you first start using PowerShell: - Execution of script files are disabled by default. You need to use the Set-ExecutionPolicy cmdlet to allow script execution, and for desktop editions you need to enable remote management. Both has secure-by-default values. To enable script execution: Set-ExecutionPolicy RemoteSigned LocalMachine I.e. scripts that originates from the Internet (downloaded through a browser or received through mail/IM/etc) or other untrusted zones require digital signatures to run; locally authored scripts are allowed to run with no digital signatures. To enable remote management run this command: Enable-PSRemoting On Windows Server versions it is now assumed that the administrator will want to use remote management, so it is enabled by default for servers. For desktops you'll need to set it through a group policy or with the command above.
viraptor 11y ago
Better than Unix tools may be debatable. (Syntax for basic file operations is a bit verbose) But it's definitely better integrated into overall system administration than any shell available on Unix.
kbenson 11y ago
It has it's pros and cons, but in the end it's fundamentally different. Powershell wouldn't work nearly as well on a UNIX system, where much of the tooling is already just text, provided by many different sources, and uses a much more diverse set of utilities. Text makes a good lowest common denominator in that situation.
- tatterdemalion 11y ago
  "Text" only makes a good lowest common denominator on UNIX because the designers of UNIX decided that ASCII would be the lowest common denominator of the system. The designers of modern Windows decided that MSIL objects would be their lowest common denominator. If the UNIX designers had chosen some other lowest common denominator, all of these diverse utilities would be communicating over that protocol instead of ASCII. The choice to use "text" came first and the ecosystem came afterward.
  - pdkl95 11y ago
    man locale(1) Non-ASCII has been supported for a long time.
    - tatterdemalion 11y ago
      This is obviously not what I was talking about. I was talking about data representations heterogenous to the idea of "text". I used "ASCII" instead of "text" to stress that "text" is just a protocol like anything else. The UNIX I'm running is set to use UTF8.
  - MrQuincle 11y ago
    Can you explain me a bit the difference if you mind (I don't know much about Windows). In Linux/Unix I can also pipe audio to /dev/audio for example. And image processing through a sequence of steps by pipes is quite often done. Are these objects coming with default metaparameters to make piping easier? Or are there other things implemented that might be cool?
pjc50 11y ago
It's almost better. It's good for automating some system administration tasks. It's not so good for text processing; there are a number of traps and mis-steps. The object pipelines are great, but have to be held in memory (you can't pipe an intermediate state to disk). By default text output wraps at the terminal width even if you're writing to a file, which is just stupid and inconvenient for further automatic processing. In order to write a script, you first have to change your system security settings. More subtly, because it's comparatively new it's not very dogfooded and there isn't a rich source of examples. UNIX systems usually have lots of shell scripts in /etc for you to learn from.
x1024 11y ago
Haha, yes. Microsoft has always delivered things that are "better" than the standards they are written against.

It's petty but I can't get over the case sensitive command names with capital letters in it. They are honestly too long.

oblio 11y ago
It has aliases for 90% of those commands, though.
AndrewGaspar 11y ago
PowerShell is not case sensitive.

vezzy-fnord 11y ago

It might be better than Bourne or C-derived shells, but I have a hard time conceding it beats for instance Inferno shell, es or rc.

kbenson 11y ago
I know enough and have had enough tangential contact with PowerShell to know that it works on a fundamentally different paradigm, as it does not pipe text, but objects. As such, it's hard to say it's "better" since it's so different. I would hazard that it's better some respects for some things, and the reverse is true as well. It fits well into windows, but would not fit well into UNIX systems, where most things are already just text. I haven't used inforno-shell, es or rc, so can't comment on them directly. That said, if they are easily comparable to bash, ksh, etc, then you probably owe it to yourself to see what powershell is about and why it's fundamentally different.
- vezzy-fnord 11y ago
  That said, if they are easily comparable to bash, ksh, etc I specifically contrasted them against Bourne or C-like shells, so I thought that much was clear that they are not. I have tried PowerShell. I think this comment summarizes it well: https://lobste.rs/s/vzjalp/why_i_dislike_systemd/comments/sh8yvt#c_sh8yvt https://lobste.rs/s/vzjalp/why_i_dislike_systemd/comments/sh...
  - moron4hire 11y ago
    That's because shells on Windows aren't management tools. That role is filled by Group Policy.
  - useerup 11y ago
    That comment is utterly uninformed. If you want to run a script simultaneously on a number of hosts, you use the Invoke-Command cmdlet (or it's alias icm). If you want to stop a process, you use Stop-Process (or it's alias kill). To copy files or directories you use the Copy-Item cmdlet (or one of it's aliases cp and copy). Hence, to stop WINWORD on a host1, host2 and host3 and then copy a directory from host0 to each of them, you would write: icm host1,host2,host3 {kill -name WINWORD; cp \\host0\C$\source C:\dest } As simple as it should be! The commenter is correct that you cannot start an application in another session from remote. However, this is a security restriction that prevents cross-session contamination and shatter attacks. It is a (security) limitation of Windows, not of PowerShell. Under Windows, all services run in session 0, the interactive user run in session 1, and if more users log on (e.g. remotely through PowerShell) they are each created in their own session. Windows put severe restrictions on what programs can do cross-session - even if the processes run under the same user account: They cannot send messages, interact with the desktop windows, inject code, start threads etc. The commenter also alludes to other security settings that you'll encounter when you first start using PowerShell: - Execution of script files are disabled by default. You need to use the Set-ExecutionPolicy cmdlet to allow script execution, and for desktop editions you need to enable remote management. Both has secure-by-default values. To enable script execution: Set-ExecutionPolicy RemoteSigned LocalMachine I.e. scripts that originates from the Internet (downloaded through a browser or received through mail/IM/etc) or other untrusted zones require digital signatures to run; locally authored scripts are allowed to run with no digital signatures. To enable remote management run this command: Enable-PSRemoting On Windows Server versions it is now assumed that the administrator will want to use remote management, so it is enabled by default for servers. For desktops you'll need to set it through a group policy or with the command above.

viraptor 11y ago

Better than Unix tools may be debatable. (Syntax for basic file operations is a bit verbose) But it's definitely better integrated into overall system administration than any shell available on Unix.

kbenson 11y ago

It has it's pros and cons, but in the end it's fundamentally different. Powershell wouldn't work nearly as well on a UNIX system, where much of the tooling is already just text, provided by many different sources, and uses a much more diverse set of utilities. Text makes a good lowest common denominator in that situation.

tatterdemalion 11y ago
"Text" only makes a good lowest common denominator on UNIX because the designers of UNIX decided that ASCII would be the lowest common denominator of the system. The designers of modern Windows decided that MSIL objects would be their lowest common denominator. If the UNIX designers had chosen some other lowest common denominator, all of these diverse utilities would be communicating over that protocol instead of ASCII. The choice to use "text" came first and the ecosystem came afterward.
- pdkl95 11y ago
  man locale(1) Non-ASCII has been supported for a long time.
  - tatterdemalion 11y ago
    This is obviously not what I was talking about. I was talking about data representations heterogenous to the idea of "text". I used "ASCII" instead of "text" to stress that "text" is just a protocol like anything else. The UNIX I'm running is set to use UTF8.
- MrQuincle 11y ago
  Can you explain me a bit the difference if you mind (I don't know much about Windows). In Linux/Unix I can also pipe audio to /dev/audio for example. And image processing through a sequence of steps by pipes is quite often done. Are these objects coming with default metaparameters to make piping easier? Or are there other things implemented that might be cool?

pjc50 11y ago

It's almost better. It's good for automating some system administration tasks. It's not so good for text processing; there are a number of traps and mis-steps. The object pipelines are great, but have to be held in memory (you can't pipe an intermediate state to disk). By default text output wraps at the terminal width even if you're writing to a file, which is just stupid and inconvenient for further automatic processing. In order to write a script, you first have to change your system security settings. More subtly, because it's comparatively new it's not very dogfooded and there isn't a rich source of examples. UNIX systems usually have lots of shell scripts in /etc for you to learn from.

x1024 11y ago

Haha, yes. Microsoft has always delivered things that are "better" than the standards they are written against.