141–150 of 164 posts
Why would you even want to make Windows command line better, instead of using a state of the art command line of Linux via a VM running in Windows, if you really cannot escape the Windows realm ?
Because a VM is overkill and won't allow you to interact with the Windows host.
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…
I am a big fan of Powershell, yet...and there had to be a "yet", now didn't there?...the Bash based criticism is well grounded even if not always perfectly articulated. I see it this way, the great thing about Powershell commands is that I get back an object. The great thing about Bash commands is that I get back text. The object is great because I don't have to parse it. The text is great because I can parse it. The…
Is it possible for Powershell to output the object as JSON so that you can see what you can read from the object?
Earlier quoted context omitted.
I am a big fan of Powershell, yet...and there had to be a "yet", now didn't there?...the Bash based criticism is well grounded even if not always perfectly articulated. I see it this way, the great thing about Powershell commands is that I get back an object. The great thing about Bash commands is that I get back text. The object is great because I don't have to parse it. The text is great because I can parse it. The…
I've never used Powershell. Is it possible for Powershell to output the object as JSON so that you can see what you can read from the object?
dir | ConvertTo-Html
dir | ConvertTo-Xml
dir | ConvertTo-Csv
Earlier quoted context omitted.
I am a big fan of Powershell, yet...and there had to be a "yet", now didn't there?...the Bash based criticism is well grounded even if not always perfectly articulated. I see it this way, the great thing about Powershell commands is that I get back an object. The great thing about Bash commands is that I get back text. The object is great because I don't have to parse it. The text is great because I can parse it. The…
I've never used Powershell. Is it possible for Powershell to output the object as JSON so that you can see what you can read from the object?
At that point, I either know the name of the method I'm looking for or I don't. In the first case the conversion to JSON doesn't do me any good because I can just call the method directly using `object.method(value)`. In the second case, it doesn't do any good because I don't know the method I want.
Reflection looks more like this: http://stackoverflow.com/questions/9952391/use-get-member-fo...
Earlier quoted context omitted.
Hmm, just installed clink 0.4.7 (with autorun disabled for now). "clink autorun --help" consistently crashes. But at least it hasn't taken down the console yet, so I guess I'll try it out for some time. It's really a nice concept.
mmmrrrm, don't know, don't remember. I do know that when I start ConEmu, I have to ctrl-alt-J to get command line features. So maybe I had trouble with autorun too? Don't remember.
> clink autorun --help
Clink v0.4.4 [git:a60c0a] Copyright (c) 2014 Martin Ridgers
http://mridgers.github.io/clink
-i, --install Installs an autorun entry for cmd.exe.
-u, --uninstall Uninstalls an autorun entry.
-s, --show Displays the current autorun settings.
-v, --value Sets the autorun to .
-h, --help Shows this help text.
-- Pass that follow '--' on to Clink.
>clink autorun --show
native : "C:\Program Files (x86)\clink\0.4.4\clink" inject --profile "~\clink"
wow64 : "C:\Program Files (x86)\clink\0.4.4\clink" inject --profile "~\clink"This viewpoint is just plain wrong. Since GUIs typically don't have a way of doing sequences of commands other than clicking and waiting, then clicking again, or of automatically making decisions, the biggest reason to use a CLI would be to express things that you can't with a GUI - like anything that requires a flow-of-control with if-then-else.
After all, that's one of the reasons that rebuses are fun - they're indeterminate and it's fun to de-ambiguate them. It's less fun to have to do all de-ambiguation yourself, when a simple pipeline or while-loop would do the trick.
Earlier quoted context omitted.
Learning Bash is just as cryptic. At least powershell function names have logic behind them.
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…
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. Some commands use -v for version, others use -V (e.g. python does), and some use --version.
GNU's long option format is a partial solution to that, but involves more typing. E.g. --verbose or --version or --invert. Also the command lines get longer then. No perfect solution as of now.
You're right, over the years, with more and more people creating commands, and with no well-defined standard in the earlier years at least, the whole scene of command line tool names and options has become something of a mess. Later one some sort of standards and conventions have been created or evolved, informally, but not many command creators necessarily follow them.
http://pubs.opengroup.org/onlinepubs/009696899/basedefs/xbd_...
Also, they are pretty detailed, so it is somewhat time-consuming and complex to implement those guidelines in full.
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 f…
If you look at the note properties that get added to the objects, they're consistent across providers:
PS C:\> (Get-Item c:\).PSPath
Microsoft.PowerShell.Core\FileSystem::C:\
PS C:\> (Get-Item env:username).PSPath
Microsoft.PowerShell.Core\Environment::username
PS C:\> (Get-Item HKLM:\software).PSPath
Microsoft.PowerShell.Core\Registry::HKEY_LOCAL_MACHINE\software
There's also some magic that you can do with tab completion to see the properties. For example, if you type...
(Get-ChildItem c:\ | sort).
...and hit tab, you can tab through the list of properties of the objects returned by Get-ChildItem when it's used on the FileSystem provider. (Don't ask me how the hell that works, though...)
I tried both ConEmu (twice) and Console2 in the past, but both were too unstable for regular use. If someone can convince me that the situation has markedly improved, I might try again, but I guess I'll just wait until we upgrade to Windows 10 at my workplace (which they say is any day now).
Happy ConEmu plus clink user for at least a year, I suspect more, but I don't keep track, I just move on.
The power of the unix command line is mostly from the utility commands themselves, not from the shell language/ecosystem. Nobody seems to be super enthusiastic about bash as a language (see all of the "at this point I just go to perl/python/etc" comments), but the commands themselves are super powerful and flexible. If you put in the time to really learn the commands and their flags, you can do quite a lot. Watching experienced unix users at the prompt, I routinely think "oh nice, that's a great command to have", but rarely "oh that's a handy language feature" or "wow Bash made that really easy".
With Powershell, it's kind of the opposite IMO. The language and ecosystem are mostly well-thought-out, consistent, and powerful. Everything-is-typed, pervasive and awesome tab-completion, mature pipeline system, decoupling of data and how it's displayed, access to the .NET standard libs, ease of extensibility and scripting (oh god it's so nice never neededing to parse arguments!), reflective help system and discoverability features, easily hostable in other apps... That all comes from the ecosystem. Where Powershell often falls flat is the limited set of built-in commands, or the lack of sensible flags/options for those commands which do exist. You're often falling back to legacy cmd.exe-era executable utils, or invoking some .NET API, both of which result in more verbose, awkward code. e.g. reading/writing the registry is SUCH A PAIN with powershell builtins (why?!?!?), so reg.exe it is. Much of that comes from Powershell's relative youth (the set of builtins and their flags is still evolving), and the relative script-unfriendliness of Windows as an OS compared to unix.
So for a particular action, in unix you have have a utility (or even N utilities) with 15 arguments to handle 95% of possible cases, in Powershell you'll get a cmdlet with maybe 5 or 6 arguments that handles 75% of cases, but the output is an object so the remaining 25% can be done by calling some method or grabbing a field. Both approaches have their strengths and drawbacks. The Powershell approach tends to scale better, I'd say - you can create fairly large scripts/packages in pure Powershell without needing to bail out to Python or C#.