OSDev.org

... what.

I was not expecting this. I've seen START refuse multiple arguments in this way, but I just assumed START was poorly implemented. I never expected DIR to refuse multiple arguments too! I suppose there must be a way to get DIR to list N named files in a directory, but this simple obvious and traditional way is not it. CMD.EXE's DIR accepts multiple arguments, it's just PowerShell's DIR which refuses them. Oh, I wonder, does PowerShell have a list syntax?

The error message gives away the secret: there's no "dir" command in PowerShell. You're actually using the Get-ChildItem cmdlet!


Indeed it does, although in PowerShell they're called arrays. Insert commas between your file names to turn them into an array.

Thanks!

...Aaand I see it's yet another language which refuses trailing commas. That's going to render impossible my habitual way of coding complex option lists. Can I concatenate list variables instead... probably, but I now see what kind of language PowerShell is: you have to explicitly specify everything. If I wanted to use a language this complex for little everyday tasks, I'd use Python because I know it already. Also, concatenating lists in Python uses the good old + operator and I don't have to look it up. I guess I'll install Cygwin or 9pm again, or maybe Tcl; weird as it is, because I half-way know it, too.

Is it that bad to specify everything? And for the record, PowerShell also uses + operator, though I imagine you looked that up already.


You could use WSL. Actually; if you simply want bash, you can just install bash on Windows, no?

¯\_ _/¯
It's not even a question of using a list; find under PS rejects wildcards. I can only suppose M$ considers the find command obsolete and not to be used with PS. I could install grep. I could use cmd instead of PS, but it never was a good shell.



Yes, it is that bad.


These days, Bash for Windows means WSL unless you use Cygwin or Msys2. I've had Msys2 installed before; it was problematic with my health issues. I installed Cygwin the other day, and it looks like it'll be worse. What's been happening is that my health has been preventing me from even looking at technical things for months at a time. Sooner or later, this breaks any rolling-release system, making it impossible to upgrade because critical parts of the system have changed too much since the last upgrade. This killed my last Msys2 installation, it has killed Termux installations on Android too, and it has killed quite a number of my native Linux installs over the years.

I may be able to use a more suitable distro under WSL, but I'm so tired of the whole Linux scene that this is something of a last resort. I'm more likely to use Msys2 again, (primarily because I'm familiar with it,) and when it breaks I'll simply back up the homedir and reinstall it. As home is on a native Windows filesystem, this will be simple.

The command seems to be working for me, I think? I'm not familiar with cmd, but here is what it does for me on both.

If I were to take a guess, I think it's the PowerShell parsing messing you up. Perhaps, it replaces "*.fth" with whatever it thinks should go there? Because the EXE program that's being run seems to be the same. You could try the following:

Though from what I can understand on how cmd's find works, this should be the equivalent:

Or if you want to go down each directory recursively:

Also, I don't exactly see how you have to specify "everything" in PowerShell exactly? I'm not familiar with cmd, but I have used bash quite a bit. I don't see how it's that much more verbose, really. Mind explaining?

Scratch what I said here. I've switched to Linux some time ago (I think it has been a few months, not sure) and I see it clearly now. Bash is just so much cleaner. I was brainwashed by Windows

I know, right? And I'm used to Rc (from Plan 9) which is even cleaner than Bash.


Today's entertainment:

Today I learned Bash's `complete -r cmd` -- removal of custom completion for cmd -- doesn't work. It'll show the custom completion as removed until the next time you try completion with that command, then it'll come back. I'm pretty sure this bug is a great many years old and is partially responsible for my growing disenfranchisement with Linux as it progressed. It's hard to remember all the bugs which have tripped me up while I was trying to do something else entirely. They tend to be the sort of bug where I don't have all the information the maintainers demand because I was focused on something other than their... junk. I've reported it to the MSYS2 project, (I'm not in a position to test bash itself,) but the state of their bug reporting form doesn't fill me with hope.

Anyway, the reason I'm posting it here is because none of the the solutions feel clean. Reporting the bug to MSYS2 means I have to check a lot of boxes which don't apply because the checkbox which does apply doesn't exist, and I haven't done any customization to create problems there. Bash will let me remove all completions; it works. This is similar to how Bash was when I first used Linux, and it's... better than broken completion but not great. Removing all completions and then rebuilding the list means a big list in my Bash startup scripts which doesn't feel clean. Fixing the list of custom completions at the source, in the installed shell startup files... I still have PTSD from the first few Linux distros I used.

The whole situation arose because I woke up in the mood to do some OS dev for the first time in ages. Checking my Forth files, I found a dir I'd forgotten about and decided to use Diff in cleaning it up. Diff leads to Bash. Bash leads to frustration. Frustration leads to anger. Anger is the path to the dark side.