-- Those who don't understand Unix are condemned to reinvent it, poorly.
Henry Spencer
Introducing the Windows Pseudo Console (ConPty)
111–120 of 196 posts
Re: Introducing the Windows Pseudo Console (ConPty)
#112Earlier quoted context omitted.
Powershell doesn't get any credit for the tab completion when the default behavior for it just makes the verbosity even more of a nuisance. Having tab completion scroll through all the possible completions one at a time doesn't save keystrokes in most cases, especially when there are dozens or hundreds of options that are really long so when you give up on tab completion and decide to type it out manually in full, yo…
That's subjective opinion. I much prefer the Windows way because I can either specify additional characters or keep hitting tab to until what I want comes up. "Display all 1026 possibilities? (y or n)" certainly isn't an improvement. Not to mention of course that it tab completes things bash can't and doesn't, and all the other reasons your initial comment was wrong.
> I much prefer the Windows way because I can either specify additional characters or keep hitting tab to until what I want comes up.
You can't specify additional characters until after you've erased all of the incorrect trailing characters that powershell filled in, and that's where powershell's completion method runs up the keystroke count unreasonably. Your comparison isn't valid if you ignore that aspect. It's also not very subjective at all. We're talking about objectively countable keystrokes.
I will concede that out of the box bash doesn't offer completion for anything other than file and command names, but it does include a programmable completion feature and many packages provide completion rules for their commands. It's up to the distro to determine whether to enable all of those completion rules by default or to stick with the more limited but predictable file-only completion behavior.
Aside from that, I can't see what "all the other reasons your initial comment was wrong" are; you appear to have only cited the existence of concise aliases for some commands as a refutation, and that obviously doesn't put powershell ahead of bash in any way, just lessens the severity of that downside.
Re: Introducing the Windows Pseudo Console (ConPty)
#113Earlier quoted context omitted.
I've considered before that you could allow each end of a pipe to set name/value attributes, which can be read by the other end.
And now you're reinventing the Windows Console API... :) I mean, both approaches have their pluses, but the API approach is only ever going to work well for remoting if it is standardized and interoperable. And the installed base of Unix termcap/terminfo programs is huge, so plain old text-with-in-band-controls is not going away anytime soon.
With things like SIGWINCH / ioctl(TIOCGWINSZ) we already know what kind of API it is, we are just haggling about the price.
Re: Introducing the Windows Pseudo Console (ConPty)
#114I hope control-S (XOFF) is disabled by default.
Re: Introducing the Windows Pseudo Console (ConPty)
#115Earlier quoted context omitted.
I think u/paulie_a is just asking for a better shell. If cmd can't be made better, then make a new one.
Exactly, I understand there are different underlying concepts and systems to the front end and what it interacts with. It just seem incredible that windows is basically stuck with a windows 95 interface for a shell.
Powershell is open source, the 6.1 preview 4 is nice and fast, and you get real objects with keys rather than scraping for regexs all the time like bash.
Re: Introducing the Windows Pseudo Console (ConPty)
#116I've been waiting for two decades to revise this particular Frequently Given Answer. * http://jdebp.info./FGA/capture-console-win32.html
I suppose it's mostly TUI programs, which use low level console API. So did you try to capture output of something like Far Manager[0]? If so, will it be much simpler to parse escape sequences of VT100?
Re: Introducing the Windows Pseudo Console (ConPty)
#117Earlier quoted context omitted.
What is with all you people who used PowerShell for a grand total of 10 seconds, gave up because it wasn't bash, then go on to complain about completely false things? PowerShell has aliases. It has shortened aliases for all the common commandlets. You can create your own aliases if you want. PowerShell has tab completion on commandlets, arguments, flags, and variable names. FFS... Every time I run into another one of…
Powershell doesn't get any credit for the tab completion when the default behavior for it just makes the verbosity even more of a nuisance. Having tab completion scroll through all the possible completions one at a time doesn't save keystrokes in most cases, especially when there are dozens or hundreds of options that are really long so when you give up on tab completion and decide to type it out manually in full, yo…
I prefer the way bash did it too, so I choose to do the same on powershell:
http://stackoverflow.com/questions/39221953/can-i-make-power...
Set-PSReadlineKeyHandler -Chord Tab -Function MenuCompleteRe: Introducing the Windows Pseudo Console (ConPty)
#118Earlier quoted context omitted.
Is there any chance cmd and powershell will improve from a user interface perspective? And perhaps become usable? Cmd has been garbage since it's inception.
cmd is parked for pretty much everything except for major issues. It's a scary codebase that has a LOT of code that's dependent on it, and we can't really add any new features there without the possibility of breaking someone. This feature is mostly focused on the other end of the communication, on being able to create new Terminal windows to run shells inside of them.
Any chance that you could just fork it? Create cmd2.exe, hell you could even open-source it.
Re: Introducing the Windows Pseudo Console (ConPty)
#119This is pretty huge. For as long as I can remember the response to command line applications talking to command line applications was "Why would you want to do that? Use (RPC | shared memory | some other IPC mechanism)." And nobody at Microsoft seemed to understand how much simpler it was to use ptys. They seem to have completely capitulated to the notion ptys and are dropping them into the next release of W10. I wis…
I understand this as a "compatibility with * nix" existing software, not as an "amazing feature." Can anybody suggest why I should like it, except for the compatibility with the software written for * nix terminals? Even ssh being too interconnected with a terminal down to the many details was a shock for me... I expected the simple encryption mechanism, over which whatever communicates, even if that would implement the "sh" part of it only on top of that, but no, it's everything spaghettisized and recombined with everything unnecessary like emulating the devices that don't exist for many decades -- in something that should have a clear separation between the task of transporting encrypted data with authenticating from anything else. I can't see it as being positive, security-wise.
Isn't it strange that today everybody has very powerful GPUs and CPUs and the graphical displays with immense RAM and then using all that to emulate the terminals last existing decades ago appears to be so important, even for something that should be just a secure communication protocol?
Why do we still spend so much energy to decide which console of many decades ago we "support" when it seems that all are flawed, at least compared to what the modern OSes can provide, as soon as the "compatibility" is not needed?
Isn't all that "hardware console" compatibility stuff just a historical accident from the "bad old days" of 300 baud lines between the mainframe and the "terminal" which had a few bytes of RAM total? In the days when e.g. the Thunderbolt 3 can carry 5 GB/s, and the rest of the hardware matches? Why do people still so cling to it? I'd really like to know what I am missing.
Re: Introducing the Windows Pseudo Console (ConPty)
#120Earlier quoted context omitted.
> I've been under the guise for most of my career that doubling a digit leads to huge benefits that I'm too comp-sci ignorant to understand. I was confused about this for years, too. But it turns out it's just a problem of bad naming . Happens more in this industry than we'd like to admit. As other explained, it boils down to UTF-16 being 16-bit, and UTF-8 being anything from 8- to 32-bit. It should have been named U…
UTF-16 is a variable-length encoding using up to two code units which each are 16-bits wide. UTF-8 is a variable-length encoding using up to 4 code units (though it used to be up to 6, and could again be up to 6) each of which are 8-bits wide. Both, UTF-16 and UTF-8 are variable-length encodings! UTF-32 is not variable-length, but even so, the way Unicode works a character like ´ (á) can be written in two diffe…
Thanks. It turns out I was even more confused than I thought I was.