O Windows inicializa o caminho para o CMD e o Powershell no login. Você precisará fazer logoff e voltar antes de verificar os novos diretórios.
Eu armazenei scripts de powershell comumente usados em %USERPROFILE%\Bin . Eu criei uma variável de ambiente USER_BIN que adicionei à variável de ambiente PATH do usuário via Control Panel > System and Security > System > Advanced system setting > Environment Variables .
Quando eu insiro o nome de um script armazenado em Bin , ou seja, my-script.ps1 , em um prompt cmd ou powershell, recebo a mensagem my-script.ps1 : The term 'my-script.ps1' 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.
Se eu fornecer o caminho completo, ou seja, C:\Users\Ari\Bin\my-script.ps1 , o script funciona bem.
O Windows inicializa o caminho para o CMD e o Powershell no login. Você precisará fazer logoff e voltar antes de verificar os novos diretórios.
É um recurso de segurança do powershell. Você só pode invocar scripts por caminho relativo ou absoluto, mas não por nome de arquivo.
To run a script, type the path and name of the script file. The path is required, even when the script is located in the current directory, to make it more difficult for malicious code to run scripts. The file name extension is optional and, as always, Windows PowerShell is not case sensitive.
O raciocínio por trás dessa decisão é o seguinte:
One trick malicious users commonly attempt in other shells is creating a script with the same file name as a built-in command. So, for example, if you wanted a user to run your script, you might name it Dir.ps1 and drop it into a folder. If you convinced the user to type Dir and press Enter, your script could run, not the Dir command the user was expecting. This technique is called command hijacking. In Windows PowerShell, you must always provide a path to such a script, making Windows PowerShell pretty well protected against command hijacking. Running demo1 doesn't work, since there's no path, but running ./demo1 does work. This is because I've now specified a path—the current folder. That command line is less likely to be confused with a built-in command since you'd never type any kind of path if you were referring to a built-in command. Thus, requiring a path helps Windows PowerShell avoid command hijacking and confusion over what might happen when you press Enter.
Tags windows-8 powershell path script