Hacker News Reader

Comment by ygra | Hacker News Reader

Curious about PowerShell misbehaving there. Care to share any details? Typically you never want to handle paths to files as strings, or at least resolve them to File/DirectoryInfo objects as soon as possible. But the only real blunder regarding paths in PowerShell I'm aware of is the Path parameter to various cmdlets and having [] in file names (which is why LiteralPath always exists alongside Path parameters).

View on HN

Came here to mention []. For those who haven't looked it up, in addition to * and ? as wildcard characters, PowerShell supports "[xyz]" and "[a-z]", meaning "x y or z" and "anything from a to z", so "[a-z]alls" would match calls, falls, walls, etc.

I knew the guy who tested the feature in PowerShell and he was deeply frustrated over the fact that there was no way to escape some sequences. For example, you can loosely match "[abc]" with something like "?abc?" or "[[]abc?" because the [[] indicates exactly one opening square bracket but there's no way (as far as I know) to say "this section ends with a square bracket".

The PM really wanted that feature, though, even though you could probably count on one hand how many times it's been used in real life.

Edit: That guy down there corrected my example.

Uh... You can escape these sequences. But the escape character isn't the backslash for obvious reasons (it's the path separator). It's the backtick.

    > ni '[abc]'

        Directory: C:\Users\<user>

    Mode                 LastWriteTime         Length Name
    ----                 -------------         ------ ----
    -a---          21/04/2023    12:23              0 [abc]

    > gi '[abc]'

    # no output - would have matched files named a, b, or c

    > gi '`[abc`]'

        Directory: C:\Users\<user>

    Mode                 LastWriteTime         Length Name
    ----                 -------------         ------ ----
    -a---          21/04/2023    12:23              0 [abc]

    > gi -LiteralPath '[abc]'

        Directory: C:\Users\<user>

    Mode                 LastWriteTime         Length Name
    ----                 -------------         ------ ----
    -a---          21/04/2023    12:23              0 [abc]

    > gi -lp '[abc]'

        Directory: C:\Users\<user>

    Mode                 LastWriteTime         Length Name
    ----                 -------------         ------ ----
    -a---          21/04/2023    12:23              0 [abc]

As far as I know that's been in powershell forever.

Ah, OK. This works because you're using single quotes on your strings, meaning the escape sequence `[ is preserved until it reaches the globbing layer. This will not work, for example...

  gi "`[abc`]"

...because the `[ will be processed before the string gets sent to globbing, meaning the back tick will be removed. This would work with double quotes:

  gi "``[abc``]"

...because at the command line level this will evaluate to `[abc`] and the globbing will know that the square brackets are literal. So I will concede and downgrade my complaint from "impossible" to merely "overly complicated for the layman".

Anyone used to scripting languages knows there's a difference between single quotes and double quotes for escaping.

> Anyone used to scripting languages knows there's a difference between single quotes and double quotes for escaping.

Not necessarily. There are all sorts of scripting languages where single and double quotes are identical.

It is, however, super common for there to be escaping differences in shell scripting languages.

$args[x] breaks. Get-Content breaks. probably more.

...admittedly i'm not the best with Powershell. There are probably workarounds or things that i did wrong.

Just put them in quotes. PowerShell is infinitely better than bash/zsh/... at handling spaces. You're spreading nonsense.

> Just use quotes bro

Man, it's never that simple. How about generating Powershell scripts with quotes? Sometimes you are dealing with escape characters \", sometimes you aren't. Why bother with all that? Hell, versions of software and compilers change such behaviors either on purpose or by accident all the time. It just gets messy dude. C:\NEVER_~1\AGAIN_~1.NOP

Perhaps i'm a dinosaur still scarred by the golden olden days, but, there is no convincing me that whitespace in filenames or URLs is ever a good idea.

I don't know what to tell you. You gave two examples that aren't actually issues. But if there's no convincing you, I won't bother. Have a nice day.

> You gave two examples that aren't actually issues.

Man, i've had config files break because i saved them in UTF-8 instead of ANSI. I hope to god you never have to experience the horror... You also have a nice day.

> Man, i've had config files break because i saved them in UTF-8 instead of ANSI.

Isn't this because random Windows tools add garbage bytes to the start of the file (a "byte order marker") and then don't tell you they did this?

It's not the encoding that's the problem, it's the garbage bytes.

P.S. I do know of exactly one program that only accepts UTF-16 for its config file, and won't accept UTF-8 or ANSI.

This is getting less and less relevant.

Reply on news.ycombinator.com