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

121–130 of 164 posts

Re: A Saner Windows Command Line

#121

Post by latkin »

Touche wrote: post #20
sz4kerto wrote: post #8

Earlier quoted context omitted.

> The script was 11 lines long (vs 3 lines in Python), it was harder to read and understand. Note that this might be true for one script, and the opposite might be true for another script. Something is saner in bash, something is better in PS. They have fundamental differences (text- vs. object-based), and neither of them is better than the other in all scenarios. (At least that's my experience.)

I think it's worth noting that powershell is .NET object-based. This means you can interact with powershell objects from a .NET language but not, for example, python. To me this is the fundamental flaw of PS. It's a neat idea as long as you stay within their box, within their ecosystem. With Bash you get a wealth of tools because everything can handle text.

> With Bash you get a wealth of tools because everything can handle text.

... and all those tools work seamlessly in Powershell, too. .NET objects are passed around within Powershell, but traditional dumb text is used for out-of-proc stuff. Where is the "fatal flaw?"

I don't understand where the perceived downside is - you wish Powershell was implemented in Python, not .NET?

Re: A Saner Windows Command Line

#122

Post by Touche »

latkin wrote: post #121
Touche wrote: post #20

Earlier quoted context omitted.

I think it's worth noting that powershell is .NET object-based. This means you can interact with powershell objects from a .NET language but not, for example, python. To me this is the fundamental flaw of PS. It's a neat idea as long as you stay within their box, within their ecosystem. With Bash you get a wealth of tools because everything can handle text.

> With Bash you get a wealth of tools because everything can handle text. ... and all those tools work seamlessly in Powershell, too. .NET objects are passed around within Powershell, but traditional dumb text is used for out-of-proc stuff. Where is the "fatal flaw?" I don't understand where the perceived downside is - you wish Powershell was implemented in Python, not .NET?

> Where is the "fatal flaw?"

The fatal flaw is that I have to distinguish between "within Powershell" and "out-of-proc". I simply don't have this issue with plain text; I don't know or care what language/runtime the programs I use are written in/for because they all use the same interface.

Re: A Saner Windows Command Line

#123

Post by UK-AL »

latkin wrote: post #114
UK-AL wrote: post #103

Earlier quoted context omitted.

Dir | rni –NewName { $_.name –replace " ","_" } That command does some extra stuff, which would make the bash equivalent also complicated.

Yep. Technically the request included recursive rename, and to avoid renaming directories, but gosh that's not hard: dir -rec -file | rni –newname { $_.name –replace "_"," " } Edit: Oops, request did not include recursive, the original sample solution did. FWIW top Google results for "unix recursively rename files" give below solutions (slightly different scenarios but you get the idea). Not particularly shorter, or…

His 'rename' wasn't recursive.

Y'all are still missing the point. We live in a world where people use CoffeeScript to avoid typing a semicolon. When you Google a PowerShell problem the Google results come back looking insane. You can play code golf here all you want but even this version looks nuts to outsiders

It's a cultural problem. You don't solve it by shouting subtly-differing versions of your culture, louder. ".

You're not getting the point. Powershell is just short, and sometimes shorter if you actually learn it.

"When you Google a PowerShell problem the Google results come back looking insane" - This is a problem with the age of powershell. Bash has been around for ever, so there is lots of good quality content on the web.

Re: A Saner Windows Command Line

#124

Post by striking »

Someone1234 wrote: post #108
bitwize wrote: post #84

Earlier quoted context omitted.

PowerShell obeys the first iron law of I/O: ALL data has a type. Bash (and Unix in general) -- does not. Now of course the implementation of typed pipelines in PowerShell is clunky and forced, because typed I/O primitives do not (yet) actually exist in Windows, so all the piping is done within one process with streams of object pointers, else it doesn't work. There are other problems, too: I recall one advocate linki…

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.

Re: A Saner Windows Command Line

#125

Post by Touche »

UK-AL wrote: post #97
Touche wrote: post #86

Earlier quoted context omitted.

Languages are not the same, you'll never have interoperability; try exporting a .NET object with a 64-bit integer to be consumed by JavaScript, for example. Text wins.

You would serialise it? $obj = [PSCustomObject]@{ Number = [long]2 } $obj | ConvertTo-Json

Try with the number 9223372036854775807. Then try consuming this JSON in Node.

Re: A Saner Windows Command Line

#126

Post by thoth »

diego_moita wrote: post #54

To hear bash-people to call Powershell "non-intuitive" sounds like those immigrants that go to a foreign land, refuse to learn the local language and insist on the natives to understand their immigrant language. Or like programmers that think that every programming language should have the C syntax. Bash and Unix commands are only "intuitive" after years of practice; Powershell is not different. And it doesn't have a…

Things I like about PowerShell include objects - cmdlets return them and you can call methods. For example, you can get a list of services (get-service) and each is a ServiceController object, which you can Start(), Stop(), etc.

Things I don't like, or is a pain point for me, are those same objects. As far as I can tell, there isn't a better way to figure out what you actually are getting back from a cmdlet besides feeding output through Get-Member.

For example, what comes back from dir/ls/Get-ChildItem? Well that's a trick question because it depends on which "provider" you invoke. On a file system (dir somedirectory) you'll get back FileInfo or Directory info, for a registry hive (dir hklm:) you'll get a RegistryKey, for environment variables (dir env:) you get a DictionaryEntry, etc.

So while it is fantastic there is a general way to enumerate items, the docs have to be vague and list System.Object as what returns from Get-ChildItem and its various aliases, which isn't very useful for working with the results.

This makes forming non-trivial commands with pipelines fairly annoying because I have to feed each stage through Get-Member to even figure out what I have and what is now available; this strategy starts to break down if a pipeline stage feeds a loop, etc.

I'd love it if the ISE displayed what actual object type exists at every point of a pipeline, rather than the trial-and-error-by-Get-Member approach I've adopted. Or for there to be some better way to get the return type of a cmdlet.

PowerShell is a huge improvement over the old command prompt though.

Re: A Saner Windows Command Line

#127

Post by UK-AL »

Touche wrote: post #125
UK-AL wrote: post #97

Earlier quoted context omitted.

You would serialise it? $obj = [PSCustomObject]@{ Number = [long]2 } $obj | ConvertTo-Json

Try with the number 9223372036854775807. Then try consuming this JSON in Node.

$obj = [PSCustomObject]@{ Number = [string]9223372036854775807 } $obj | ConvertTo-Json

The lack of decent types, is surely a weakness of js?

Re: A Saner Windows Command Line

#128

Post by jrumbut »

yoodenvranx wrote: post #37
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…

> 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. I have exactly the same problem. I use Linux since about 8 years but somehow I just don't use the commandline very often so I forget stuff all the time. Because of this I have half a dozen post-its glued to my monitor for all the grep/git/whatever tricks I just can't keep in my head. And…

If you're interested in getting past this stage of learning the Linux/Bash environment, I'd recommend reading man pages.

I worked with someone who introduced me to this approach, and at first I was like "I'll just Google it again and get on with my life," but once I forced my way through a couple of them it's really opened my eyes and changed the way I use the tools available.

ls has enough options to spell most people's names (capitalization included), and a lot of grep pipelines can be replaced with options passed to grep. It turns out that we're almost always doing things the hard way or reinventing the wheel.

Re: A Saner Windows Command Line

#129

Post by tacos »

latkin wrote: post #114
UK-AL wrote: post #103

Earlier quoted context omitted.

Dir | rni –NewName { $_.name –replace " ","_" } That command does some extra stuff, which would make the bash equivalent also complicated.

Yep. Technically the request included recursive rename, and to avoid renaming directories, but gosh that's not hard: dir -rec -file | rni –newname { $_.name –replace "_"," " } Edit: Oops, request did not include recursive, the original sample solution did. FWIW top Google results for "unix recursively rename files" give below solutions (slightly different scenarios but you get the idea). Not particularly shorter, or…

That wasn't what I Googled. And Microsoft is announcing bash and Linux shell subsystems today for Windows so y'all are really missing the point. Maybe dev goes one way and ops goes another. But probably not. I'm not betting on Powershell.

Re: A Saner Windows Command Line

#130

Post by douche »

Touche wrote: post #120
13of40 wrote: post #104

Earlier quoted context omitted.

PS C:\> 0x1234567812345678 1311768465173141112 PS C:\> 0x1234567812345678 >.\foo.txt ; cat .\foo.txt 1311768465173141112 PS C:\> "WScript.Echo('$(0x1234567812345678)')" >.\foo.js ; cat .\foo.js ; cscript //nologo .\foo.js WScript.Echo(1311768465173141112) 1.31176846517314E+18 ... I'm not seeing your point.

> I'm not seeing your point. JavaScript does not have 64-bit integers. So if you exported an object with 64-bit integers to XML, for example, a JavaScript program could not (correctly) deserialize that XML.

Javascript doesn't really have integers, at all, so...
Post reply on HN