Hacker News new | past | comments | ask | show | jobs | submit login

1. The use of a multi-root hierarchy vs. a single root hierarchy is pretty arbitrary. Drive letters in turn are just an arbitrary way to define the multi-root hierarchy.

2. `mklink` [0] has existed since Windows Vista for NTFS file system. No settings toggling required.

3. What is your argument against PowerShell? In what ways does it fall short? I have been pretty successful with using it for various tasks.

4. This is about the only legit claim. Windows always requires full credentials to execute as another user. Windows does provide `runas.exe`, but you must provide the target user's full credentials.

[0] https://technet.microsoft.com/en-us/library/cc753194%28v=ws....




> `mklink` [0] has existed since Windows Vista for NTFS file system. No settings toggling required.

There are several limitations in the Windows/NTFS implementation, however:

1. You have to specify the target type (file or directory) at link creation time.

2. Creating symbolic links requires either being an Administrator user, or having the "Create symbolic links" group policy enabled for your account.

3. No real directory hard links. (EDIT: For some reason, I forgot that Linux doesn't have these, either. Maybe I was thinking of bind mounts.)


3. No real directory hard links. Junction points are close, but still distinguishable from

Windows isn't the only OS that disallows creating directory hard links.

http://askubuntu.com/questions/210741/why-are-hard-links-not...


Huh, I wonder why I misremembered that. Thanks for the correction.


> 3. What is your argument against PowerShell? In what ways does it fall short? I have been pretty successful with using it for various tasks.

Powershell is an acceptable scripting language. It's a horrible interactive shell. They shoudn't have made "shell" part of its name if they weren't going to at least include basic interactive features like readline compatibility and usable tab completion.


I'm not familiar with what you mean by readline compatibility. I see a GNU Readline library with history functions, but I'm not sure what that means being integrated into a shell, and what features you would expect to see.

My experience with tab completion in PowerShell is great. It completes file paths, command names, command parameter names, and even command parameter values if they're an enumeration. Could you describe what else you would expect to see?


Powershell's completion is worthless for the most common use case of saving keystrokes. Since it fills in the entire remaining command name and cycles through the possibilities in alphabetical order instead of completing just what's unambiguous and presenting a list of the possibilities from there, it doesn't help with typing out common prefixes and if you find yourself cycling through an unreasonably large number of possibilities you have to backspace get rid of the unwanted completion (often very long, given the naming conventions) before you can refine your search.

They took a code completion technique that works alright for an IDE and put it on the command line, losing some key usability in the process when they could have just implemented the paradigm that has been standard in the Unix world for decades.

Yes, it does a great job of identifying what the completion possibilities are in almost every context. That's good enough for an IDE, but only half the job when you're making an interactive command line shell.

As for other readline features: it's really annoying to only partially implement a well-known set of keyboard shortcuts.


See, and I personally dislike the system you mention. It bugs me to no end to have only a couple options, but the system will only fill in the common prefix. Now I have to look, figure out what's there already, figure out what the next letter is, hit it, then hit tab again. If I want to save key strokes, that what aliases and symlinks are for, not tab completion.

Also, at least in PowerShell 5, if you run the ISE instead of the cmd-based terminal, it shows an IDE-like overlay of completions while you're typing.


> if you run the ISE instead of the cmd-based terminal

PowerShell depends (or is based) in no way on cmd.


I am fairly certain that they use the same console system. For instance, right-clicking on the title bar gives the exact same options as in `cmd.exe`. I was perhaps a little overzealous in calling it cmd-based; that's a slip-up on my part simply because `cmd.exe` was the only program to use that system before. Thanks for keeping me honest.


Both use the Windows console host, effectively what a terminal emulator is on Unix-likes. It provides the window and a bunch of other functionality (character grid with attributes, history, aliases, selection, drag&drop of files into the window, etc.).

It's just that every console application on Windows uses that host. This includes cmd, PowerShell, Far Manager, or even vi. Sorry, I may have seen it conflated with cmd too often. It just nags me. For Linux users it's probably when everyone starts calling a terminal (emulator) "bash".


https://github.com/lzybkr/PSReadLine perhaps. Personally I find it nice, but it requires a bunch of tweaking to feel comfortable, but maybe less so to people who are used to readline.


Tab completion works nicely and you can even rotate through the different values a parameter can take. Also, ctrl+space lists all the options (parameters, values, files, folders) available at your cursor's position.

I would call it something more than acceptable scripting language. It is object oriented and it can easily use C# libraries, which is pretty neat.


a) That's nothing to do with the kernel.

b) http://mridgers.github.io/clink/ is bloody fantastic.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: