i can not call a In-Script Function without PowerShell ISE
When i call a function in the normal Powershell i get this Error
onboarding : The term "onboarding" was not used as the name of a cmdlet, function, script file, or
of an executable program. Check the spelling of the name or if the path is correct (if
included) and repeat the process.
In *************************************.ps1:8 characters:9
+ onboarding
+ ~~~~~~~~~~
+ CategoryInfo : ObjectNotFound: (onboarding:String) [], CommandNotFoundException
+ FullyQualifiedErrorId : CommandNotFoundException
Have in mind Mathias R. Jessen's useful comment (valid for ▶ button as well):
When you use F5 to run a script in ISE, it doesn't actually
invoke the script, it executes the contents of the editor in the
global scope of the attached console/runspace, so it'll persist after
the first attempt.
Run your script using Dot sourcing operator .
Runs a script in the current scope so that any functions, aliases, and
variables that the script creates are added to the current scope,
overriding existing ones. Parameters declared by the script become
variables. Parameters for which no value has been given become
variables with no value. However, the automatic variable $args is
preserved.
Example:
. c:\scripts\sample.ps1 1 2 -Also:3
Note. The dot sourcing operator is followed by a space. Use the space
to distinguish the dot from the dot (.) symbol that represents the
current directory.
Related
I am used to running shell scripts with for example
source script.sh
I was surprised to learn recently that this also works
. script.sh
The single dot of course normally indicates the current directory so I am now confused. Can anyone explain this use of .?
Taken from IBM docs: ".(dot) runs a shell script in the current environment and then returns. Normally, the shell runs a command file in a child shell so that changes to the environment by such commands as cd, set, and trap are local to the command file. The . (dot) command circumvents this feature.
If there are slashes in the file name, . (dot) looks for the named file. If there are no slashes . (dot) searches for file in the directories specified in the PATH variable. This may surprise some people when they use dot to run a file in the working directory, but their search rules are not set up to look at the working directory. As a result, the shell does not find the shell file."
. (dot) and source mean the same thing in the bash language.
In fact the (dot) form is the standard form according to the POSIX Shell Specification. The source form is a bash extension, but not a bash invention. (The venerable Berkley C-shell (csh) used to use source rather than ..)
According to the POSIX Shell specification, source is a command name whose meaning is unspecified; see https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html
I want to run a go get command when GOPROXY='direct', I've tried to run this command using the VS code terminal:
GOPROXY='direct' go get go.mongodb.org/mongo-driver/mongo
but I'm getting this error:
GOPROXY=direct : The term 'GOPROXY=direct' is not recognized as the name of a cmdlet,
function, script file, or operable program. Check the spelling of the name, or if a path
was included, verify that the path is correct and try again.
At line:1 char:1
+ GOPROXY='direct' go get go.mongodb.org/mongo-driver/mongo
+ ~~~~~~~~~~~~~~~~
+ CategoryInfo : ObjectNotFound: (GOPROXY=direct:String) [], CommandNotFoundEx
ception
+ FullyQualifiedErrorId : CommandNotFoundException
I've also tried:
go env set GOPROXY='direct'
but when I run go env command the GOPROXY value is still like this GOPROXY=https://proxy.golang.org,direct
and I also tried to define a GOPROXY variable in the windows environment variable and giving it the value of direct but it also failed to do the job.
Make sure your VSCode terminal is a bash one, not a CMD or Powershell.
In a CMD or Powershell, the syntax var=xxx cmd would not be correctly interpreted as: set a variable and execute a command inheriting its environment variables, including the one set.
My GitHub Actions workflow "runs-on" windows-latest. I want a custom Action which executes a PowerShell (core or legacy is fine) script. I have a parallel action that runs on Linux and MacOS. So, my .github/actions/install-tf-win directory contains this action.yml
name: install_tf_win
description: installs Terraform/TerraGrunt for Windows
runs:
using: "composite"
steps:
- run: install-tf-win\install-tf-win.ps1
shell: pwsh
The directory also contains install-tf-win.ps1. I have tried all sorts of variations on that run statement. Starting with "&" and without, variations in paths used with forwards and backwards slashes. I originally started with $GITHUB_ACTION_PATH/install-tf-win.ps1 (works for Linux/MacOS), however it seemed that GITHUB_ACTION_PATH was getting evaluated to be an empty string and then there were complaints about /install-tf-win.ps1 not being found. I tried both pwsh and powershell for the shell key value.
The form shown above results in this error:
Run ./.github/actions/install-tf-win
install-tf-win\install-tf-win.ps1: D:\a\_temp\c1d3d7fa-074b-4f90-ade0-799dcebd84ec.ps1:2
Line |
2 | install-tf-win\install-tf-win.ps1
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| The module 'install-tf-win' could not be loaded. For more information, run 'Import-Module
| install-tf-win'.
I can obviously code my way around this by just putting the PowerShell statements in a step. But, the documentation suggests this should work. https://docs.github.com/en/free-pro-team#latest/actions/creating-actions/metadata-syntax-for-github-actions#runsstepsshell .
So, how do I get this to work, please?
The error message implies that you cannot refer to your script with a relative path:
The command is passed to pwsh, PowerShell [Core]'s CLI, via its -Command (-c) parameter, which interprets the install-tf-win part of
install-tf-win\install-tf-win.ps1 as a module name rather than as a subdirectory in the absence of an actual subdirectory by that name on Windows[1], so the implication is that such a path doesn't exist.
The linked documentation, suggests that you need an absolute path, based on the GITHUB_ACTION_PATH environment variable, which in PowerShell must be referenced as $env:GITHUB_ACTION_PATH (untested):
# ...
- run: '& $env:GITHUB_ACTION_PATH/install-tf-win/install-tf-win.ps1'
shell: pwsh
Note:
The need to use &, the call operator, which is a syntactic necessity due to the script path containing a(n environment-)variable reference; the same would apply if the path were quoted - see this answer for background information.
Since & is a metacharacter in YAML when used unquoted at the start of a value, the entire string is quoted. Single-quoting ('...') is employed in this case, so that YAML doesn't interpret the contents of the string up front.
As an aside: The implication of '...'-quoting working (as confirmed by Kevin, the OP) is that when pwsh -c is ultimately called on Windows, the string's content is (properly) double-quoted ("..."), because PowerShell's CLI only recognizes " as having syntactic function for command-line argument parsing. By contrast, a '...'-quoted -c argument would be interpreted as a verbatim string rather than as a command, causing its content to be simply echoed.
[1] How PowerShell interprets a path such as foo\bar.ps1 when executed as a command, as of PowerShell 7.1
Interpreted as a command - both inside a PowerShell session and via the -Command / -c parameter of the PowerShell CLI, as used by GitHub Actions - the form foo\bar.ps1 is ambiguous:
It could refer to a module named foo, and its bar.ps1 command (even though module commands don't have .ps1 name extensions).
It could refer to a subdirectory foo and file bar.ps1 in it.
This applies to Windows only:
PowerShell first interprets the path as a file-system path.
If the path doesn't exist, it falls back to interpreting it as a module-command reference.
On Unix-like platforms - even though PowerShell generally allows you to use \ and / interchangeably as the path separator on all supported platforms - this particular path form is always interpreted as a module reference; in other words: you cannot use this syntax form to invoke a script this way (see below).
This surprising inconsistency is discussed in GitHub issue #14307.
There are two ways to avoid this ambiguity, which work on all supported platforms; the following cause PowerShell to unequivocally treat the path as file-system script path:
Use / instead of \: foo/bar.ps1
Prefix the path with .\ (or ./): .\foo\bar.ps1
(Of course, you could also use a full path.)
Note that when the -File parameter of PowerShell's is used (rather than -Command / -c), this ambiguity doesn't arise, as the argument is then always considered a (potentially relative) file-system path, even on Unix-like platforms, irrespective of whether you use \ or /.
I often accidentally type "code ," when opening vs code in a hurry. I want a bash or zsh script that can open vs code in the current directory when i type code .
I tried a function in my aliases but it was recursively calling itself. is there anyway to make an alias with two arguments?
A simple function:
code () {
command code "${1:-.}"
}
lets you just type code (no argument at all) to use the current directory, without preventing you from passing a different directory if you need to.
(This needs adjusting if code already has some special meaning if you don't pass an argument, or if you need to consider a more complicated case like ./, being the first non-option argument, rather than the first (if not only) argument.)
I would like to write a script that has several commands of the kind
> export PATH=$PREFIX/bin
Where
> $PREFIX = /home/usr
or something else. Instead of typing it into the the Shell (/bin/bash) I would run the script to execute the commands.
Tried it with sh and then with a .py script having the line,
> commands.getstatusoutput('export PATH=$PREFIX/bin')
but these result into the error "bad variable name".
Would be thankful for some ideas!
If you need to adjust PATH (or any other environment variable) via a script after your .profile and equivalents have been run, you need to 'dot' or 'source' the file containing the script:
. file_setting_path
source file_setting_path
The . notation applies to all Bourne shell derivatives, and is standardized by POSIX. The source notation is used in C shell and has infected Bash completely unnecessarily.
Note that the file (file_setting_path) can be specified as a pathname, or if it lives in a directory listed on $PATH, it will be found. It only needs to be readable; it does not have to be executable.
The way the dot command works is that it reads the named file as part of the current shell environment, rather than executing it in a sub-shell like a normal script would be executed. Normally, the sub-shell sets its environment happily, but that doesn't affect the calling script.
The bad variable name is probably just a complaint that $PREFIX is undefined.
Usually a setting of PATH would look something like
export PATH=$PATH:/new/path/to/programs
so that you retain the old PATH but add something onto the end.
You are best off putting such things in your .bashrc so that they get run every time you log in.