31–40 of 110 posts
I get perverse joy out of using the Windows CMD.EXE shell (and the earlier COMMAND.COM from MS-DOS). Yes, it's tremendously crufty, idiosyncratic, and sometimes seems down-right illogical in its behavior. Arguably, just about anything else is better, but it holds a special place in my heart.
Earlier quoted context omitted.
You can also normalize them using the dos2unix package, which is available on most distros.
Have the line ending wars ended yet? Apple is finally Unix \n, but most internet protocols are \r\n as are Windows. Though honestly, Windows just doesn't even matter any more to me, I haven't needed to touch an MS product in years...
Interestingly, when manually making a multi-line string in Powershell, only the LF character ( `n ) is needed to make a new line. Using CRLF ( 'r'n ) gives identical behavior in most strings.
Powershell is garbage. .Net does utf8 by default but powershell, built on .Net, manages not to. Try type utf8Encoded.txt > out.txt in cmd.exe and posh. Cmd works and posh fs it up. And after you do figure out utf8 encoding in posh, it'll always add a BOM just to screw you
Agree about Windows command prompt being lame compared to bash, but I really find PowerShell amazing, even more so then bash. If you look at all the recent (even not so recent) products from MS, it is clear that PowerShell is the shell for Windows, and not batch. I didn't get the cure for polio analogy that's in the article but I really think anyone that's comparing shells should compare with PowerShell.
Powershell is garbage. .Net does utf8 by default but powershell, built on .Net, manages not to. Try type utf8Encoded.txt > out.txt in cmd.exe and posh. Cmd works and posh fs it up. And after you do figure out utf8 encoding in posh, it'll always add a BOM just to screw you
Earlier quoted context omitted.
You can also normalize them using the dos2unix package, which is available on most distros.
Have the line ending wars ended yet? Apple is finally Unix \n, but most internet protocols are \r\n as are Windows. Though honestly, Windows just doesn't even matter any more to me, I haven't needed to touch an MS product in years...
\r\n, CR+LF historically speaking was the first, but \n, LF became dominant because of Unix.
Unreadable on mobile
Powershell is garbage. .Net does utf8 by default but powershell, built on .Net, manages not to. Try type utf8Encoded.txt > out.txt in cmd.exe and posh. Cmd works and posh fs it up. And after you do figure out utf8 encoding in posh, it'll always add a BOM just to screw you
You can see the difference in philosophy here, cmd (and bash, to a certain extent) are simple and don't try to do sneaky things silently, even if it means you might have to do a little more yourself e.g. performing character set translations explicitly. The behaviour is straightforward and predictable. PS attempts to be more "user-friendly" by doing some hidden conversions presumably so the user doesn't have to explicitly do character set translations, and when it works it works well; but when it fails, it fails spectacularly.
This isn't completely related to Windows command line but I thought I would post it out here. I was trying to run a Bash script from a Git repo mounted in a Docker container. When running the Bash script, I kept getting all kinds of errors. I ran the exact same script in the same Docker container on a different Linux computer that had cloned the repo. It turns out the \r Windows line endings (which I later normalized…
You can also normalize them using the dos2unix package, which is available on most distros.
In computing, "batch" connotes long running processes in addition to "script"'s connotation of collapsing multiple commands into a single one. The seemingly redundant parsing by the Batch interpreter is a feature, not a bug. 1. The parser allows modifying a .bat file during its execution and having those changes execute without restarting the Batch interperter. [1] This is in keeping with the rationale for batch proc…
But bash was around in the 80's, too, right? And it didn't seem to need those features. How did bash users get around your claimed need for this?
To a first approximation, I'd expect that 1980's Unix programmers would generally be working in environments more accepting of restarting a batch process when there was an error in the code, i.e. significantly less likely to hold a clerical or secretarial "TCP report" job in a regular commercial office. Though that split has become less likely, it's still pretty uncommon for a computer user with little control of their work environment and deadlines to be using *nix rather than Windows.