Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A Saner Windows Command Line

futurice.com

Post reply on HN
Print view View original

151–160 of 164 posts

Re: A Saner Windows Command Line

#151

Post by Rebelgecko »

Klathmon wrote: post #112
phaemon wrote: post #44

Earlier quoted context omitted.

> why is -b the flag for key length in ssh-keygen? Because the length is given in "bits". I get your point, but that's a terrible example! :-)

Now that you've said that, i'll never forget it again (although what the hell does -t stand for then?) But the point is that even though it's most likely "my fault" for not reading the manual correctly (i'm not saying you were implying that, but often i do feel that it's ultimately because of my laziness that i have these problems), they aren't "intuitive" in the sense that that you can just pick it up and go. The on…

>The one thing my "dream linux" system would borrow from powershell is the tab-completion for flags and sub-commands

You might want to check out some alternative shells: The fish shell does this out of the box, it's really nice. For something more bash-like, I think zsh can too (but you might have to set it up in a config file)

Re: A Saner Windows Command Line

#152

Post by verbatim »

striking wrote: post #124
Someone1234 wrote: post #108

Earlier quoted context omitted.

And the UNIX style has a cost: It is insecure e.g. [0][1]. Luckily modern UNIX-based systems are rarely used as multi-user terminals these days or we would see many more privilege escalations via exploiting bugs in scripts which iterate over user owned files. Even in web scenarios, most web frameworks carefully manage what is allowed in a filename or set the filename themselves. Ultimately because on UNIX there is no…

Bash scripts aren't usually intended to be secure. They're quickly written one-offs that do some tiny task and do it well, not usually exposed to an insecure environment or externally controlled input. If you want to write a good program, use a programming language that cares about good programming. Bash et al. don't care about how good the program is, they care about getting something done quick.

Well, that's what we thought before the ShellShock vulnerability ended up being a major security worry due to all of the places that bash scripts end up being used.

Re: A Saner Windows Command Line

#153

Post by striking »

verbatim wrote: post #152
striking wrote: post #124

Earlier quoted context omitted.

Bash scripts aren't usually intended to be secure. They're quickly written one-offs that do some tiny task and do it well, not usually exposed to an insecure environment or externally controlled input. If you want to write a good program, use a programming language that cares about good programming. Bash et al. don't care about how good the program is, they care about getting something done quick.

Well, that's what we thought before the ShellShock vulnerability ended up being a major security worry due to all of the places that bash scripts end up being used.

Bash doesn't come with a guarantee of usability sticker. Actually, it comes with an indemnification of liability sticker.

People who are dumb enough to hammer in screws shouldn't be building houses. Whether they do or not isn't exactly my worry.

Don't use the wrong tool for the job and you probably won't get burned.

Re: A Saner Windows Command Line

#154

Post by Pxtl »

UK-AL wrote: post #16
Pxtl wrote: post #2

At our office we jokingly refer to powershell as "two googles per line" - a term coined by its strongest proponent at the company. It thought it would come naturally over time, but it never does. It seems needlessly cryptic and verbose in so many ways. I've started using LinqPad for stuff I would normally do in cmd now.

Learning Bash is just as cryptic. At least powershell function names have logic behind them.

Point. I'm developer, not ops. I'm comparing PowerShell to true programming languages, not to Bash.

Re: A Saner Windows Command Line

#155

Post by pritambaral »

noinsight wrote: post #140
pritambaral wrote: post #83

Earlier quoted context omitted.

I didn't get this, could you elaborate? Does powershell autocomplete objects it is about to ingest, and before you run the command?

PowerShell v3+ can autocomplete command names, command switches and switch values (if they're a strict set). It can also autocomplete object properties yes. $dir = gci $dir. -> $dir.Count

> command names, command switches and switch values (if they're a strict set).

So can bash. How is this different from bash's autocompletion?

> also ... object properties

Well, there aren't objects in bash, so I can't translate this.

Re: A Saner Windows Command Line

#156

Post by Pxtl »

vram22 wrote: post #147
Klathmon wrote: post #22

Earlier quoted context omitted.

I've only been working professionally with linux for 5-ish years, but i'd say that i'm still at the "2 googles per command" number for bash. Some of it stems from the fact that i just don't use it enough, but most of it from the fact that this shit just isn't intuitive. why is -b the flag for key length in ssh-keygen? Why is -v the flag for "don't include" in grep? I have those memorized now, but there is no way they…

>>Why is -v the flag for "don't include" in grep? As user yread said, it's for inVert (the sense of the pattern match, from "matches" to "does not match"). You're right, it is non-intuitive. One of the issues is that when you use single letter options, a particular letter could potentially stand more than one expanded word, e.g. in the case of v, it is more commonly used for Verbose or Version. Even there, it varies.…

-n for negative or negate or not-in probably would have been more intuitive, but yes fundamnetally 1-character parameters is a bit limited.

Re: A Saner Windows Command Line

#157

Post by pritambaral »

13of40 wrote: post #137
pritambaral wrote: post #115

Earlier quoted context omitted.

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 ` (for Debian based OSes) Filter executable commands: ` | grep 'bin/.'` (assuming the package adheres to standards) Check parameters of command: ` --help` (again, assuming the developers have adhered to convention) Of course, if one needs to check m…

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 act…

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 .

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.

Re: A Saner Windows Command Line

#158

Post by pritambaral »

latkin wrote: post #132
pritambaral wrote: post #115

Earlier quoted context omitted.

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 ` (for Debian based OSes) Filter executable commands: ` | grep 'bin/.'` (assuming the package adheres to standards) Check parameters of command: ` --help` (again, assuming the developers have adhered to convention) Of course, if one needs to check m…

"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 credent…

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.

Re: A Saner Windows Command Line

#159

Post by Retra »

typon wrote: post #40
sz4kerto wrote: post #9

Earlier quoted context omitted.

Bash can be _extremely_ cryptic as well, we just learned it over time. Look at awk :)

Why use bash when you can use Python with os and sys modules?

Python is great for writing scripts, but not so great for doing interactive maintenance.

Re: A Saner Windows Command Line

#160

Post by ilek »

mattmanser wrote: post #17
ilek wrote: post #4

Earlier quoted context omitted.

Agree on that one, it's really verbose and ugly. I liked the idea of a cmd that integrates so nicely with .NET but I don't think it worked out this time. We use powershell a lot at work for developer setup stuff and other common tasks we do on a daily basis and at this point I've considered just writing my own language to do it or find something else.

Why don't you just use Python, Ruby or even C#? Why write your own language? I wanted to learn Ruby a while back but didn't have a web project to work on so I started writing a load of scripts in Ruby instead. It worked out fine.

C# has the same issue really, although we do it use for some other tooling and whatnot as we're a .NET shop.

Don't know much Ruby or Python to be honest so I'm not sure how could I apply them but I'll dig around sometime soon.

Post reply on HN