Live data from Hacker News

Reimagining the Windows Command Line

tltjr.github.com

61–70 of 74 posts

Re: Reimagining the Windows Command Line

#62
post #54
post #51

Earlier quoted context omitted.

>> This might be slightly off-topic, but am I the only one that thinks that command line tools are archaic with some pretty serious drawbacks? I see and acknowledge the power they can wield in the right hands, but for mere mortals it's a terrible experience. You've asked the question and answered it yourself ;-) Using a GUI over the CLI is probably preferred for 90% of the tasks 95% of the users typically perform. I…

That's a great reply! The problem is that people like me, who are somewhat technically inclined but not fulltime programmers, fall in between two chairs. I need to do some reasonably advanced stuff, but I face a steep learning curve before I can do it, and I'm not sure it's worth it since it's not my main occupation.

Just a small note to your comment above, the issues you mentioned with Symphony, they are not just because you haven't "mastered" the CLI. It sounds like they are true bugs in whatever manual or documentation accompanies Symphony, and it would be a good idea to report your experience with setting it up on their issue tracking system.

I think many people often discard technologies for their implementation rather than their ideas.

Re: Reimagining the Windows Command Line

#63
post #52

Earlier quoted context omitted.

Most of your complaints sound like problems with documentation (it existing and/or you using it) or problems with a poorly defined tool (edit), lol, or is specific to the Windows shell. I can think of several GUI apps that have ALL of those problems but I also can't script them, alias them or fix them. I spent 75% of my day in the terminal because I'm proficient and fast with it. Most of programming has a learning cu…

You make some good points, let me try to answer. First, I'm certainly not dismissing it. Yes, I'm frustrated, but I'm also aware that a lot of people much smarter than me swear by this tool, so there's obviously a lot of value there. I'm more dismayed by the learning curve. I come from a sales/marketing/ux/business kind of background so my mindset is different. I like my tools to be beautiful and intuitive. As simple…

My experience is almost the complete opposite. The first time I touched the commandline was to apt-get packages in linux. Doing this invovled me learning nothing more than apt-get install, and apt-cache search.

I slowly accumulate knowledge of how to use other programs as I needed to use them (the same way I learn how to use gui programs.) The only conceptual block for me with the command-line was the concept of piping the output of one command into another.

Re: Reimagining the Windows Command Line

#64
post #37

Earlier quoted context omitted.

> - No discoverability. proper command line shells and tools offer auto-completion and inline help. > - All sorts of opaque dependencies. Bad or unfinished products is a concept orthogonal with command line. I've had to manually install a particular unspecified version of .NET to get some graphical application to work, for instance. > - A million minor flaws and bugs. Again, totally unrelated to CLI. Most application…

> proper command line shells and tools offer auto-completion and inline help. This is not discoverability. How will it help me figure out curl's command line options? How will it help me not having to remember whether tool X wants "command [files] [options]" or "command [options] [files]" or either? How will it help me reuse something i just ls'ed into vision without having to retype half the path i just typed into t…

> How will it help me figure out curl's command line options?

Try typing "curl", the output (on Ubuntu 12.10) is: "curl: try 'curl --help' or 'curl --manual' for more information"

>How will it help me not having to remember whether tool X wants "command [files] [options]" or "command [options] [files]" or either?

Both are almost always excepted, but command [options] [files] is standard. Also, if you do something wrong, you are often given an explanation as to what you did. Also `command -h` or `man command`.

>How will it help me reuse something i just ls'ed into vision without having to retype half the path i just typed into that ls command?

Up arrow.

Re: Reimagining the Windows Command Line

#65
post #55

Is this a Windows port of wish (WIndowing SHell), or an all-new, confusingly named project (WIndows SHell)? http://en.wikipedia.org/wiki/Wish_(Unix_shell)

Quite a few people have brought this to my attention, and it is unfortunately, a confusingly named project. I was unaware of the other project and will probably consider renaming my project if it gets funded. Thanks for pointing this out though.

Re: Reimagining the Windows Command Line

#66
post #60
post #58

For most of Microsoft's lifetime, I've wondered why MS didn't just build a unix-style command line into Windows, providing a major upgrade to the ridiculous DOS. As a Windows dev, I always downloaded unix utilities for DOS and the first thing I put on any new Windows box is Cygwin. After decades of the same ol' DOS, it's obvious that MS just doesn't care about the command line. One reason I switched to Mac for Web de…

Seriously, MS has been going toward easy scripting for years: http://en.wikipedia.org/wiki/Windows_PowerShell And Powershell ISE is like bash with Intellisense. You can access .Net from Powershell and pretty much do anything you want. You can easily write new commands in C#. Everything you want is already there. You just have to step slightly out of the Unix mindset to find the Windows equivalent. And I'd have to say…

Whats an object? Some type of file?

Re: Reimagining the Windows Command Line

#67

I'm actually glad for the inefficiency of the Windows command-line. Every time I boot up into Windows to test something, I'm reminded of how much I hate it. Since moving to Linux, development is just easier in every way: * viM instead of Visual Studio has made me a better programmer * think more, guess less * I can keep customizations when I remote in and patch production code * Bash is much more productive than .bat…

>If Windows had a decent command-line (with decent documentation of course), I might convince myself to put up with less malleable tools just to play games without rebooting.

Isn't the point of a commandline that it makes basic tools far more malleable? For example, I recently was working with an OCR tool that took as an input 1 image file path, and an output name, and extracted plaintext from the image.

If this were a gui tool, I would be stuck manually running it on hundreds of images at once. As a command-ling tool, I can do: `find . | grep *.jpg | xargs -n 1 -I{} | tesseract '{}' '{}'`

Re: Reimagining the Windows Command Line

#68
post #52

Earlier quoted context omitted.

Most of your complaints sound like problems with documentation (it existing and/or you using it) or problems with a poorly defined tool (edit), lol, or is specific to the Windows shell. I can think of several GUI apps that have ALL of those problems but I also can't script them, alias them or fix them. I spent 75% of my day in the terminal because I'm proficient and fast with it. Most of programming has a learning cu…

You make some good points, let me try to answer. First, I'm certainly not dismissing it. Yes, I'm frustrated, but I'm also aware that a lot of people much smarter than me swear by this tool, so there's obviously a lot of value there. I'm more dismayed by the learning curve. I come from a sales/marketing/ux/business kind of background so my mindset is different. I like my tools to be beautiful and intuitive. As simple…

>I don't see any easy solutions to this, but I think it's a problem.

Computers are complicated. Most users have no idea how hard. You HAVE to be willing to learn. I honestly have no idea what you expect and I don't think you do either. I don't honestly think there's anything to do.

Re: Reimagining the Windows Command Line

#69
post #60

Earlier quoted context omitted.

Seriously, MS has been going toward easy scripting for years: http://en.wikipedia.org/wiki/Windows_PowerShell And Powershell ISE is like bash with Intellisense. You can access .Net from Powershell and pretty much do anything you want. You can easily write new commands in C#. Everything you want is already there. You just have to step slightly out of the Unix mindset to find the Windows equivalent. And I'd have to say…

Whats an object? Some type of file?

I can best explain via example. Let's say I want to iterate through a directory and do something to each file:

  ls C:\ | foreach{echo $_.Name}
That will print out the file name. The $_ variable represents each file object that ls returns. Let's say I want the file creation times instead:

  ls C:\ | foreach{echo $_.CreationTime}
Or just the day of the week the file was created:

  ls C:\ | foreach{echo $_.CreationTime.DayOfWeek}
It's incredibly powerful. And the default is always a text representation of the object anyway, so it seems like text is getting piped, just like Unix. If you do this:

  ls C:\ | foreach{echo $_}
You get a typical directory listing.

Re: Reimagining the Windows Command Line

#70
post #57

Earlier quoted context omitted.

If these are the problems you see with CLI, then you're doing it wrong. - Discoverability: tab completion, apropos manpages, listing out your search path directories, using your Debian GNU/Linux distribution's package management tools to search / explain packages and commands. - Dependencies: Debian GNU/Linux, APT, and policy. There's a reason I'm an unrepentant bigot. Debian-based distros are a fair substitute. RPM…

the "kid" seems to be on windows, which ha a crappy cli in a non posix env , which makes it even more difficult to use with a cli...

Even there, a substantial number of issues can be addressed through Cygwin, though its packaging features still leave a lot to be desired.
Post reply on HN