3 ms·

Haven't used PS much – only used DuckDuckGo to find what each PS command meant, so it's possible I have misuderstood some, but – these are the bash alternatives

13of40 11y ago
What's the bash equivalent of something like this? Get-Command -Module SQLPS | ?{$_.Parameters.Values.ParameterType -contains [PSCredential]} In PowerShell, this means "show me all the commands from the SQLPS module that take a credential object as one of the parameters".
- pritambaral 11y ago
  This question weighs to powershell's side, and I wouldn't call it fair (and not just because I don't know powershell), but I'll bite. Print all files in package: `dpkg -L <package name>` (for Debian based OSes) Filter executable commands: ` | grep 'bin/.'` (assuming the package adheres to standards) Check parameters of command: `<command> --help` (again, assuming the developers have adhered to convention) Of course, if one needs to check multiple commands, one will have to use a loop. (Which is basic programming, isn't it?).
  - latkin 11y ago
    "Which commands from XYZ package require credentials?" hardly seems unfair. Your suggestion solutions illustrate the point well - you have to memorize some convention of where utils are located, how they display usage info, then cross your fingers and hope developers have followed it. And it's not even complete, since I'm guessing there is no solid convention for parsing a manpage to find which args represent credentials. In powershell, cmdlets and their args are typed, so you just ask for all cmdlets that have an arg with the credential type. Everything above is tab-completable, too, and thus discoverable at least to some level.
    - pritambaral 11y ago
      Memorization is a necessity in every endeavour involving a process, even a computer is nothing without some form of memory. Like you remember powershell commands and switches and whatnot, I remember where executables are placed. It may be a convention, but that's only because a restriction hasn't been placed (yay, freedom?); for all practical purposes, it is a rule. Crossing fingers and hoping devs have followed a rule/convention/sensibility happens everywhere that isn't 100% under one's own control. Like I have to cross my fingers when installing from an .exe or .msi. > I'm guessing there is no solid convention for parsing a manpage to ... You guess wrong. (There is no convention for parsing a manpage, only for writing one, but isn't that enough?) > Everything above is tab-completable So it is in the *nix world. Check out oh-my-zsh (if bash's tab-completion wasn't enough for you), it has an option to enable a ridiculous (and annoying, IMO) amount of tab-completion.
  - 13of40 11y ago
    But can't you see that's bad? 1. It doesn't work on all distros, and even on Debian you need to already know that "dpkg -L" gets a list of commands. I tried googling "debian distro package tool" and it doesn't tell me about dpkg. Discoverability. 2. The reason you're praying that the package developer put everything in 'bin' is because there's no metadata to distinguish between commands and other files. 3. You're actually executing(!!) the commands to get the help, because, again, no metadata. Parsing the arguments is delegated to the command, so what if the command ignores the --help and reboots your server instead? (Note that if you run a PowerShell cmdlet with -?, it doesn't actually hand control over to the command.) 4. At the end of the day it's not going to work because all of the parameters are strings and all you can look for is the parameter name, which might be "password" or "pass" or "pwd" or anything else the author picked. (Another reason this matters is the PSCredential is stongly-typed and backed by a SecureString, so if the process crashes it won't get leaked into the heap dump. In your Linux command it's just a plain-text string on the heap.) Now, I'm not trying to say you should give up bash/Linux and become a Windows fan boy. I'm saying you need to take an honest look at bash and decide whether it makes sense to stick with that paradigm in the 21st century.
    - pritambaral 11y ago
      1. Every distro has its own package tool, and a user (if they're going to be messing with packages) is expected to know them. If a dev/admin can't use `dpkg -L` on Arch Linux, it is their fault for not learning Arch Linux. I wouldn't expect you to know about dpkg from one Google search, like you wouldn't expect me to know about '?{$_.Parameters.Values.ParameterType' from one Google search, would you? 2. The location of the file IS the metadata! Placing a command outside a bin/ folder in a Debian package is the same as mistyping <whatever metadata lets Get-Command know something is a command>. 3.1. Yeah, sure, executing is bad. So use the manual pages. They are well structured (the structure is parsed every time they are displayed, for example). 3.2 Executing is not that bad, when you trust the source of the commands. It is anti-convention to use arbitrary, non-vetted repos. 4. Looking for a single value is always better than looking for three values, but is the latter really that much more bad? BTW, taking a password as a string argument is wrong in the Linux world too. C'mon, people aren't that stupid. As for where you store it: unless you're handing it over to hardware immediately, there's little protection to it. I did a little bit of searching on what SecureString is (admittedly, not much, maybe you can enlighten me), and is there any reason to believe the encryption key isn't in memory too? Bash alone isn't what's keeping me on Linux or away from Windows. When bash becomes bad/obsolete/uncool, another will take its place. Or if a new feature seems good/worthwhile/cool, it can get added to bash. The secret (heh) is: open source. Fish happened, zsh happened, and it was easier for them to happen because bash was open source. If they had to reimplement all of bash from scratch, it would have been a little bit discouraging, a little bit too hard, but thankfully it wasn't. I doubt I'll hardly ever become a fanboy of anything, even Linux, but I'm not going to look at Windows in the same light until the magic of open source has worked on it.

13of40 11y ago

What's the bash equivalent of something like this? Get-Command -Module SQLPS | ?{$_.Parameters.Values.ParameterType -contains [PSCredential]} In PowerShell, this means "show me all the commands from the SQLPS module that take a credential object as one of the parameters".

pritambaral 11y ago
This question weighs to powershell's side, and I wouldn't call it fair (and not just because I don't know powershell), but I'll bite. Print all files in package: `dpkg -L <package name>` (for Debian based OSes) Filter executable commands: ` | grep 'bin/.'` (assuming the package adheres to standards) Check parameters of command: `<command> --help` (again, assuming the developers have adhered to convention) Of course, if one needs to check multiple commands, one will have to use a loop. (Which is basic programming, isn't it?).
- latkin 11y ago
  "Which commands from XYZ package require credentials?" hardly seems unfair. Your suggestion solutions illustrate the point well - you have to memorize some convention of where utils are located, how they display usage info, then cross your fingers and hope developers have followed it. And it's not even complete, since I'm guessing there is no solid convention for parsing a manpage to find which args represent credentials. In powershell, cmdlets and their args are typed, so you just ask for all cmdlets that have an arg with the credential type. Everything above is tab-completable, too, and thus discoverable at least to some level.
  - pritambaral 11y ago
    Memorization is a necessity in every endeavour involving a process, even a computer is nothing without some form of memory. Like you remember powershell commands and switches and whatnot, I remember where executables are placed. It may be a convention, but that's only because a restriction hasn't been placed (yay, freedom?); for all practical purposes, it is a rule. Crossing fingers and hoping devs have followed a rule/convention/sensibility happens everywhere that isn't 100% under one's own control. Like I have to cross my fingers when installing from an .exe or .msi. > I'm guessing there is no solid convention for parsing a manpage to ... You guess wrong. (There is no convention for parsing a manpage, only for writing one, but isn't that enough?) > Everything above is tab-completable So it is in the *nix world. Check out oh-my-zsh (if bash's tab-completion wasn't enough for you), it has an option to enable a ridiculous (and annoying, IMO) amount of tab-completion.
- 13of40 11y ago
  But can't you see that's bad? 1. It doesn't work on all distros, and even on Debian you need to already know that "dpkg -L" gets a list of commands. I tried googling "debian distro package tool" and it doesn't tell me about dpkg. Discoverability. 2. The reason you're praying that the package developer put everything in 'bin' is because there's no metadata to distinguish between commands and other files. 3. You're actually executing(!!) the commands to get the help, because, again, no metadata. Parsing the arguments is delegated to the command, so what if the command ignores the --help and reboots your server instead? (Note that if you run a PowerShell cmdlet with -?, it doesn't actually hand control over to the command.) 4. At the end of the day it's not going to work because all of the parameters are strings and all you can look for is the parameter name, which might be "password" or "pass" or "pwd" or anything else the author picked. (Another reason this matters is the PSCredential is stongly-typed and backed by a SecureString, so if the process crashes it won't get leaked into the heap dump. In your Linux command it's just a plain-text string on the heap.) Now, I'm not trying to say you should give up bash/Linux and become a Windows fan boy. I'm saying you need to take an honest look at bash and decide whether it makes sense to stick with that paradigm in the 21st century.
  - pritambaral 11y ago
    1. Every distro has its own package tool, and a user (if they're going to be messing with packages) is expected to know them. If a dev/admin can't use `dpkg -L` on Arch Linux, it is their fault for not learning Arch Linux. I wouldn't expect you to know about dpkg from one Google search, like you wouldn't expect me to know about '?{$_.Parameters.Values.ParameterType' from one Google search, would you? 2. The location of the file IS the metadata! Placing a command outside a bin/ folder in a Debian package is the same as mistyping <whatever metadata lets Get-Command know something is a command>. 3.1. Yeah, sure, executing is bad. So use the manual pages. They are well structured (the structure is parsed every time they are displayed, for example). 3.2 Executing is not that bad, when you trust the source of the commands. It is anti-convention to use arbitrary, non-vetted repos. 4. Looking for a single value is always better than looking for three values, but is the latter really that much more bad? BTW, taking a password as a string argument is wrong in the Linux world too. C'mon, people aren't that stupid. As for where you store it: unless you're handing it over to hardware immediately, there's little protection to it. I did a little bit of searching on what SecureString is (admittedly, not much, maybe you can enlighten me), and is there any reason to believe the encryption key isn't in memory too? Bash alone isn't what's keeping me on Linux or away from Windows. When bash becomes bad/obsolete/uncool, another will take its place. Or if a new feature seems good/worthwhile/cool, it can get added to bash. The secret (heh) is: open source. Fish happened, zsh happened, and it was easier for them to happen because bash was open source. If they had to reimplement all of bash from scratch, it would have been a little bit discouraging, a little bit too hard, but thankfully it wasn't. I doubt I'll hardly ever become a fanboy of anything, even Linux, but I'm not going to look at Windows in the same light until the magic of open source has worked on it.