I find myself missing the . in dot sourced files and spending a little time getting my footing when switching from C# to PS. Is there a way to alias the . or use a similar command that is more blatantly noticeable?
In short: No, you cannot define an alias for . :
., the (dot-)sourcing operator, is an operator and as such it cannot be the target of an alias (only commands can).
Defining a function is also not an option, because it would itself have to be dot-sourced when called, in order to be able to dot-source other commands (scripts whose definitions to load into the caller's scope).
Related
What I would like to archieve is to be able to use :< shell command and add the output to the shell command to the cursor's position in neovim.
It seems I could use :redir to archieve this functionality and wrap it in to a function.
Is there a way to associate a [neo]vim function to :command?
A command can't return value. Hence a command is not an expression. And in particular, commands never can be "nested" one into another, like function calls. Cf. Shell scripting, for example.
In principle, there are some tricks, like a builtin function that accepts command name, runs it, and returns output as string value. But this is rather "convenient redir", not "syntax breaker".
To add external tool output into cursor position use, for example,
put=system('blah blah')
This is legal, as (some of) commands may accept expressions, including function calls.
Make sure to escape "bars" and "double quotes" though, as (sometimes) they are special in VimScript.
9/10 times if you are trying to use the Invoke-Expression cmdlet, there is a better way. Building the arguments to a command dynamically? Use an array of arguments. Building the arguments to a cmdlet? Use splatting with an array or hashtable. Your command has a space in the path to it? Use the call operator (&).
This might seem open ended, but Invoke-Expression is an easily accessible cmdlet where the answer is almost always to never use it. But the cmdlet exists for a reason, is not deprecated, and most criticisms of its use state something similar to, "it's almost never the right answer", but never states when it is acceptable to use it. In what case is it acceptable to use Invoke-Expression? Or to word it a bit less openly, how was Invoke-Expression designed to be used?
To quote from a PowerShell team blog post titled Invoke-Expression considered harmful (emphasis added):
The bottom line: Invoke-Expression is a powerful and useful command for some scenarios such as creating new scripts at runtime, but in general, if you find yourself using Invoke-Expression, you should ask yourself, or maybe a respected colleague if there is a better way.
EBGreen notes:
Or to phrase it another way, It [Invoke-Expression] is ok to use as long as a user is never involved in any part of generating the string that will be invoked. But even then, not using it will enforce better habits than using it would.
In short:
As a matter of habit, always consider a different (usually more robust and secure) solution first.
If you do find that Invoke-Expression is your only choice, carefully consider the security implications: if a string from an (untrusted) outside source (e.g., user input) is passed directly to Invoke-Expression, arbitrary commands may be executed.
Therefore: Only use Invoke-Expression if you fully control or implicitly trust the input.
Note: As of Windows PowerShell v5.1 / PowerShell Core v6.1.0, the official Invoke-Expression help topic doesn't provide such guidance; this GitHub issue suggests rectifying that.
Rare examples of justified (safe) use of Invoke-Expression:
Creating PSv5+ custom classes dynamically:
so that the class can be used in a remote session.
so that the set of properties can be created based on conditions at runtime.
Using Invoke-Expression in combination with Write-Output:
to parse a string with embedded quoting, with extra precautions.
to parse command lines stored in a file, if trusted.
Using Invoke-Expression for nested property access:
via a property path stored in a string.
I am trying to alter the standard logic used by fish to find filename completions. In particular, I want fish not to consider any filename that ends in a tilde (~) character, as these are emacs backup files and are not interesting.
I had assumed that the list of possible completions would be provided by a fish function, which I could then edit to remove the ones ending in tildes. But I cannot find the function. I have looked in the documentation at fishshell.com, and I have also tried functions | grep complete. What function should I be editing?
Unlike most completions file name completions is not implemented as a function; it's baked into the C++ code. See the completer_t::complete_param_expand() method in src/complete.cpp. If you can make a cogent argument for how this type of customization would be implemented I'd encourage you to open an issue.
P.S., Note that functions will not show private functions unless you invoke it as functions -a. I mention this because many completion functions are marked private by beginning their name with an underscore.
I have written a set of PowerShell helper functions for the Micrsosoft TFS and Micrsosoft TFPT command line tools (some which in turn use the Posh cmdlets included with TFPT). To shorten the commands from their standard naming conventions, like Get-TfsStatus and Invoke-TfsCommit, I created aliases as well (e.g. tf-status and tf-commit). I use PowerTab as well for tab completion, but v0.99.6 does not support tab completion with aliases by default.
How do you configure tab completion so that my aliases, which all start with tf- can show me the list of available commands?
I see that PowerTab includes an editor for modifying tab expansion behavior, but it is not clear to me exactly what I would need to configure. I also know with PowerTab turned off, the default posh tab completion works with aliases.
Example function and alias:
function Get-TfsStatus([switch]$all) {
# Do something
}
Set-Alias tf-status Get-TfsStatus
Set-Alias tf-st Get-TfsStatus
Note: Originally, I had the actual function names as tf-status, tf-commit, etc., but when you Import-Module, PowerShell complains that I was not following the naming standards for PowerShell functions.
This is not a use case I had anticipated, so it is not well supported. However, there is an easy way to hack this in so long as your aliases continue to have a "-" in their name.
Edit line 957 of TabExpansionCore.ps1 to add "Alias" to the list of command types.
Get-Command -CommandType Alias,Function,ExternalScript,Filter,Cmdlet -Name "$($Matches[1])*" |
First off, you can use non-standard names for your functions without getting warnings.
Import-Module <<path_to_your_module>> -DisableNameChecking
Although, from experience, it is a good habit to follow (in most cases) the naming convention.
By default, autocomplete does not work on aliases. What does work, even for aliases, is parameter completion. So whether you type tf-status -a or Get-TfsStatus -a, if you press Tab, it will autocomplete to -All.
Neither the Powershell console nor the ISE editor have an option to enable alias completion.
For your case, I would suggest to use the "wrong" name (no alias), import with -DisableNameChecking and the autocomplete will then work for tf-status.
Concerning PowerTab -- this is not fully supported in all hosts. Check this page to see which functionality is supported where. I don't know it well - I'm sure it's possible to add aliases, but it might be a tedious task and would need to be done for each user. If someone doesn't have powertab, they won't be able to use autocompletion for the aliases you define in your module.
By default Powershell requires ".\" before any local executable. So to execute local command in Powershell you need type something like
.\foo arg1
How to turn requirement to type ".\" off, so I can run just like
foo arg1
And what is the correct name of the ".\"?
.is the current directory and \is the path separator. That means .\foo is the relative path to the foo program.
If .is not included in your PATH environment variable, you have to specify it as above. To avoid that, you could add . to your PATH variable. But as a rule of thumb, never do so, since it leads to security risks. Better use .\foo or even better provide the absolute path.
It is a security feature to make sure you run only the executables at the desired location. This ensures that you are running the right executable and not a hijacked one.
This is a language / shell implementation and you cannot turn it off, IMO.
you can't turn it off, however you could turn your could put your functions in a module (or even a script you load somewhere else), and load that then at least calling those functions looks nicer (without the .\foo
perhaps . isn't in the path, the tabcompletion function detect that, so if you write foo[TAB] then automatically is expanded to .\foo. For this reason i don't see where is the "extra work" putting the dot and the slash if tabcompletions takes care of that.