undefined | Better HN

0 pointsptx2y ago0 comments

At least it doesn't let you do this (as far as I can tell) so it seems slightly better in that aspect:

  value="1 -o 1"
  if [ $value -eq 10 ]; then
    echo "Value is exactly 10."
  fi

The syntax is terrible, though – if these operators are not actually options for a command, which is the context where the leading dash makes some kind of sense, why make them look like that?

Also, why does the documentation[0] talk about statements returning values? I've never seen the terminology used that way before. Usually expressions evaluate to a value and statements can consist of an single expression.

[0] https://learn.microsoft.com/en-us/powershell/module/microsof...

0 comments

3 comments · 1 top-level

jodrellblank2y ago· 2 in thread

What else would the operators be? They can't use `>` because that does IO redirection, they can't use `|` for OR because that's piping.

They could use `==` for equality but then what symbols would -ceq and -ieq be?

What symbols or what else would work for `-match` and `-in` and `-cmatch`?

If they were just `eq` or did use `==` how would that work for when they are actually options to a cmdlet such as `| where-object -eq $x` ?

wvenable2y ago

They didn't need to copy any awful shell syntax. We have decades of programming language development but Powershell cribs from oldest and most cobbled together environment. Give up on the old syntax for IO redirection and piping.

I also don't even like their verb-noun philosophy because it's impossible to figure out what the commands are and there are so many. It's still all objects and methods underneath but you can't auto-complete anything.

jodrellblank2y ago

> "Give up on the old syntax for IO redirection and piping."

Handwaving away decades of muscle memory and expectations for > and | seems bad, but those are the easy cases, and you've avoided dealing with the operators which are not symbols and the case sensitive/insensitive variants of common operators. What do you suggest for syntax instead which handles all, or most, of the cases PowerShell handles?

We have had "decades of programming language development" but I'm not aware of any which do what PowerShell does. I haven't spent any time on OilShell or NuShell or other Unix-shell-modernised systems, but Python syntax and behaviour does not make for a good shell, nor do any other programming-language-with-REPL that I've used. What language are you thinking of which makes a good compromise of both shell and pipeline and programming language, which would also work in the Windows world where things aren't text (PowerShell design priority)?

> "I also don't even like their verb-noun philosophy because it's impossible to figure out what the commands are and there are so many."

On a computer system where many thousands of things are possible, specifying what to do by command line is going to require typing one thing for every option you need to specify. Whether that's in the command name, in the command options, in the arguments to the options, or externalised in some ENV variable or /sys/ namespace or some /proc/ data source or some /etc or .dotfile config option, or hiding in some JSON structure, it's only shuffling the complexity around. At least with many commands they are organised into modules, searchable, and can have associated help.

> "you can't auto-complete anything."

*date*<tab> cycles through all commands with 'date' in their name. Cmdlets and binaries and functions.

hyper-v\*failover*<tab> cycles through all cmdlets in the Hyper-V module which have 'failover' in their name.

Get-Command -Noun VHD searches for commands with VHD as the noun part of Verb-Noun.

Get-Command -Parameter VlanId searches for commands which take -VlanId as a parameter (e.g. Hyper-V\Set-VMNetworkAdapterVlan).

j / k navigate · click thread line to collapse