8000 Provide a syntax to call native binaries when its name is aliased · Issue #1975 · PowerShell/PowerShell · GitHub
[go: up one dir, main page]

Skip to content

Provide a syntax to call native binaries when its name is aliased #1975

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
be5invis opened this issue Aug 20, 2016 · 12 comments
Closed

Provide a syntax to call native binaries when its name is aliased #1975

be5invis opened this issue Aug 20, 2016 · 12 comments
Labels
Issue-Enhancement the issue is more of a feature request than a bug Resolution-Declined The proposed feature is declined. WG-Engine core PowerShell engine, interpreter, and runtime

Comments

@be5invis
Copy link

Like, if I have both gsn (as an alias) and gsn (as a script on Linux with Shebang), the latter one is unaccessable (unless you provide its full path).

@lzybkr
Copy link
Contributor
lzybkr commented Aug 20, 2016

On Windows, it's common to use an extension, e.g. gsn.exe, but obviously that won't help on Linux.

A full path (or relative path) is the most obvious way to invoke an external command, but we do have a syntax (admittedly obscure) if you don't know the path:

& (Get-Command -CommandType Application gsn)

The & operator is the invocation operator - which is more often used to invoke commands with spaces in the path or to execute a command whose name is in a variable. In my example above, because of strong typing, the invocation operator recognizes the output of Get-Command (an instance of something deriving from System.Management.Automation.CommandInfo) and correctly calls that command, allowing you to override the default command resolution algorithm.

That said, I agree a better syntax is needed for Linux.

< 8000 /form>
@be5invis
Copy link
Author

@lzybkr How about “:gsn”? I am not sure whether this prefix is occupied...

@lzybkr
Copy link
Contributor
lzybkr commented Aug 20, 2016

That would be a breaking change - admittedly unlikely to cause problems, but a breaking change nonetheless:

function :gsn { 'in gsn' }
:gsn

The above has worked since V1 - it likely wasn't intentional - I can't say for sure, I joined the team during V2.

@be5invis
Copy link
Author
be5invis commented Aug 21, 2016

@lzybkr So, according to your code adding any functions are breaking because... its name may be used in a user’s script.
These prefixed names are just “last-resort” binding, as a supplement of the existing variable resolution rules: when a name is not bound to anything else, try to find a native program with the same name.

@ForNeVeR
Copy link
Contributor

What about @? It seems that you aren't allowed to call a function using @. Although it already have a meaning of splat operator. E.g. get-childitem @ls will now be ambiguous.

@BrucePay
Copy link
Collaborator
BrucePay commented Aug 21, 2016

The ability to use ":gsn" was intentional. Per POSIX, any valid file name character can be used in a command name (where the legal filename characters varying between file systems).
With respect to @gsn, you can always use quoting to disambiguate e,g, Get-ChildItem "@gsn".
We do have an existing notation --% which tells parser to stop quote and expansion processing - we might be able to tweak that though it would be technically breaking but probably wouldn't really break anything, One other possibility is to simply keep using the .exe suffix syntax and give it the semantic that it looks for a native command without the suffix on *NIX systems e.g. 'gsn.exe' is mapped to "gsn"

@GeeLaw
Copy link
GeeLaw commented Aug 22, 2016

Start-Process abc I guess this should work if you have proper file association, or Invoke-Item. If those are not available on PowerShell for *nix that's bad.

@ForNeVeR
Copy link
Contributor
ForNeVeR commented Aug 22, 2016

Probably something like this could do the trick even without language changes (we'll need to add only one new simple command and a convenience alias):

function Call-NativeCommand ($cmd) {
    & (Get-Command -CommandType Application $cmd) @args
}

New-Alias ^ Call-NativeCommand

After that you'll be able to do the following:

$ New-Alias curl echo # ensure that curl is an alias for something
$ curl --version # the alias got called
--version
$ ^ curl --version # the real binary got called
curl 7.28.1 (i386-pc-win32) [...]

Although I'm not sure how this will work with --% parser extension. Calling a native command with --% is probably a common use case, so we'll need to think about it.

@SteveL-MSFT SteveL-MSFT added WG-Engine core PowerShell engine, interpreter, and runtime Issue-Enhancement the issue is more of a feature request than a bug labels Sep 29, 2016
@SteveL-MSFT SteveL-MSFT added the Up-for-Grabs Up-for-grabs issues are not high priorities, and may be opportunities for external contributors label Oct 28, 2016
@iSazonov
Copy link
Collaborator
iSazonov commented Oct 7, 2017

Bash workarounds:

\ls
"ls"
'ls'
/usr/bin/ls
command ls
unalias ls; ls

@riotrah
Copy link
riotrah commented Jan 1, 2023

Hi, I hate to be that "updates" guy, but given the sheer amount of time and the abrupt drop-off in comms here (ie, nothing suggesting any show-stoppers etc), I can't tell if work has moved elsewhere without updating this issue, or if this is in fact the state of affairs still.

(fwiw I think the latter is alright, though I'd love to then know if there's a way the community can help move this forward that y'all can advise on)

@SeeminglyScience SeeminglyScience added the Needs-Triage The issue is new and needs to be triaged by a work group. label Jan 3, 2023
@vexx32 vexx32 self-assigned this Jan 9, 2023
@vexx32
Copy link
Collaborator
vexx32 commented Jan 9, 2023

WG-Engine discussed this today.

We don't think the value of the proposed feature here meets the bar for making a potentially breaking language-level change. There are workarounds available that folks here have mentioned, and there are also arguments to be made about avoiding such name collisions in the first place whenever possible.

Thanks for submitting this request, but ultimately we feel this is not something that we could accept as a language change.

@vexx32 vexx32 added Resolution-Declined The proposed feature is declined. and removed Needs-Triage The issue is new and needs to be triaged by a work group. labels Jan 9, 2023
@vexx32 vexx32 removed their assignment Jan 9, 2023
@vexx32 vexx32 removed the Up-for-Grabs Up-for-grabs issues are not high priorities, and may be opportunities for external contributors label Jan 9, 2023
@ghost
Copy link
ghost commented Jan 11, 2023

This issue has been marked as declined and has not had any activity for 1 day. It has been closed for housekeeping purposes.

@ghost ghost closed this as completed Jan 11, 2023
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Issue-Enhancement the issue is more of a feature request than a bug Resolution-Declined The proposed feature is declined. WG-Engine core PowerShell engine, interpreter, and runtime
Projects
None yet
Development

No branches or pull requests

10 participants
0