3 ms·
This is pretty much what I've idealized for a new shell. Where every program can just output a standard table of information for each action. No need to have th
by devwastaken 7y ago
This is pretty much what I've idealized for a new shell. Where every program can just output a standard table of information for each action. No need to have the program itself be queried for it every time, or find all the right options. You just get all the data, and filter what you want programaticly.
- vthriller 7y ago> You just get all the data, and filter what you want programaticly. There are definitely cases when you're better off with producer-side filtering. For example, `find` allows you to not traverse certain directories with -prune, which might save a lot of resources.
- jodrellblank 7y agoPowerShell has a lot of "corrections" of this kind, to get producer-side filtering. e.g. Getting all Windows Eventlogs, then filtering client side turned out to be quite bad, so Get-EventLog became Get-WinEvent with a lot more filtering controls. Cmdlets which get data, like Get-AdUser or Get-MessageTrackingLog in Exchange, or Get-CimInstance often have a lot of common filtering parameters as well as a more general -Filter or -Query "build your own". Big source of annoyance where you can't do that, but might want to.
- felixfbecker 7y agoIt also generally applies to concept of wildcards/globs not just to file paths, but many parameters. So a cmdlet like Get-User with a -Name parameter to get a user with a certain name can also be called with John* to get all users with first name John. In my experience the filtering options are pretty consistent