Problem
I'm trying to start a virtual environment with an environment variable using pipenv. These are the steps that I followed:
I created a pipenv virtual environment
Ran echo ENV_VAR=my_token > .env
I started the virtual environment by running pipenv shell
When I ran that last command, I received the error:
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xff in position 0: invalid start byte
I'm using PowerShell on Windows 10.
Question
Why might this happen? Clearly is some odd character getting in there, but I'm using a normal keyboard.
Context
If I simply create my .env file instead, everything works as expected. Is there something weird that happens with echo?
Additional
As requested by Giacomo Catenazzi below, I've looked at the file using Notepad++. It is in UTF-16 BOM. So the echo command simply does not work very well with PowerShell to write to UTF-8.
Related
I installed an application named lqns in the path: /home/robb/Research/dist/lqns-6.2/lqns (lqns is a folder containing the executable lqns). I want the program to be executed in command line simply calling lqns in the shell, I solved this adding to the file ~/.bashrc the line:
export PATH=$PATH:/home/robb/Research/dist/lqns-6.2/lqns
And it works with no issue. I am now trying to execute this program inside a Matlab script, running:
[status, ~] = system("lqns " + filename, '-echo');
Where filename is the path of an input file. I get the error message:
/bin/bash: line 1: lqns: command not found
Running the exact same command with the shell I get no error: the program runs with no problem generating the relative output.
Running getenv('PATH'); in Matlab and printenv PATH on my OS shell I indeed get two different results: Matlab does't have the path to lqns. I even tried editing manually the files /etc/environment, /etc/bash.bashrc and /root/.bashrc, with no result. How can I solve this issue?
you need to launch matlab by typing matlab in a terminal, not by double clicking on its shortcut from your desktop. (or even typing ./matlab in a terminal from your desktop)
it's up to the operating system to determine what double clicking does, and it's not guaranteed to execute most of your shell initialization scripts (or even launch it from the correct shell to begin with).
more info at Why are environment variables not resolved when double-clicking .desktop file?
AutoHotKey cannot insert numbers on the WSL unless I use codepoints
I would like to use python3 every time I use pipenv. For that, I need to insert: pip --python /usr/bin/python3 etc.. However, I don't want to type --python /usr/bin/python3 every time, and therefore I have automated that part with an AutoHotKey script.
The following line works fine when I type the hotstring in any place such as a Notepad file or a path bar:
::pipenv::pipenv --python /usr/bin/python3
When I type pipenv in, say, Notepad, the string pipenv --python /usr/bin/python3 is inserted.
However, if I type it on the WSL (Windows Subsytem for Linux), then I get:
pipenv 66python LusrLbinLpython·
I get the same result in CMD, but surprisingly not in PowerShell (where I get the expected output).
To make it work on the command line, I had to re-write my script using hexadecimal codepoints (or entity references, not sure what the proper name is) instead of the characters themselves:
::pipenv::pipenv {U+2D}{U+2D}python {U+2F}usr{U+2F}bin{U+2F}python{U+33}
That way the output is the expected pipenv --python /usr/bin/python3 both on the command line and in any other environment. I'm surprised that this is the case, because those characters (-, / and 3) are normal ASCII characters, so I don't understand why using codepoints is necessary.
The AutoHotKey script contains UTF-8 Unicode (with BOM) text, with CRLF line terminators.
In a nutshell, I have managed to make the script work. The reason for opening this question is to understand why this happens. Thanks.
I'm running a script in solaris 11 with different results depending of the shell used.
The script has an echo redirecting to a file given by an environment value:
echo "STARTING EXEC" >> $FILE
ps. EXEC is just the message the script show, it's not using exec command.
If I execute the script without the variable FILE defined (using /usr/bin/ksh):
./start.sh[10]: : cannot open
and the script continue the execution.
The flags for ksh are:
echo $-
imsuBGEl
But if I change to /usr/xpg4/bin/sh, the script show me the echo in stdout and there is no error shown.
The flags for xpg4 sh are:
echo $-
imsu
I tried to change the flags with set +- (I can't remove El flags, but BG are removed ok), but can't get the same behavior.
Is there anything I can do to get the same result using ksh without cannot open error?
/usr/bin/ksh --version
version sh (AT&T Research) 93u 2011-02-08
I'll want the script keep going, showing the message in stdout, instead of showing the error just like it does now.
Like shellter said in the comments, the good thing to do is to check if the FILE variable is defined before doing anything. This is a script migration from an HPUX to a SOLARIS environment, and client think they must have the same result as before (we unset FILE variable before execution to test it).
You are likely running Solaris 11, not Solaris 64.
Should you want to have your scripts to work under Solaris 11 without having to search everywhere the bogus redirections, you can simply replace all shebangs (first line) by #!/usr/xpg4/bin/sh.
The final solution we are going to take is to install the ksh88 package and use it like default shell (/usr/sunos/bin/ksh). This shell have the same behavior the client had before, and we can let the scripts with no modifications.
The ksh used in solaris 11 is the 93 (http://docs.oracle.com/cd/E23824_01/html/E24456/userenv-1.html#shell-1)
Thanks #jlliagre and #shellter for your help.
I have changed the shell key in windows registry to gain custom shell (Kiosk usage):
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows
NT\CurrentVersion\Winlogon]
I set shell key to a batch file which runs two applications as below:
start "myFirstAppTitle" "myAppPath\myApp1.exe"
start "mySecondAppTitle" "myAppPath\myApp2.exe"
Each application runs but the second application which needs some files to be excuted throws an error which says could not find dependency files. whereas the dependency files are adjoining to the exe file and the mentioned app works fine, when starts from startup.
Meanwhile when i run the batch file manually it rusn fine.
I added the PATH command to the batch file but it did't work too.
Change the batch file to this:
set PATH=%PATH%;C:\MyAppPath
start "myFirstAppTitle" "myApp1.exe"
start "mySecondAppTitle" "myApp2.exe"
If you start executables without an absolute path, the path is relative to the current working directory. Also, when you specify an executable with a relative path, %PATH% is not searched for a matching subfolder with a matching executable.
Since the script worked when you manually started it, your working directory probably was C:\. However, when run at logon as a replacement shell, the working directory is most likely "%SystemRoot%\system32".
The problem solved strangely, i removed the title parameter of start command and it worked. In fact i used start command this fashion:
set PATH=%PATH%;C:\MyAppPath
start myapp.exe
start myapp2.exe
I am running this command in powershell:
sqlplus system/passwd#mydb #my_sql
I have tried it with and without backticks and various other versions I found via Google. I keep getting an error when the command is passed off to sqlplus and have been unsucessful in finding the fix. Hopefully someone here can help out?
The error I get is:
Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
SP2-0042: unknown command " ■#" - rest of line ignored.
So I am sucessfully connecting to the database but there is an extra character being passed to sqlplus in front of the '#'. " ■#" in notepad++ looks like " ¦#"
If you created your SQL command file using a redirect (> or >>) in powershell - like:
myProgram > mySQL.out
and then run it like:
&sqlplus mypw/myuser#mydb.xyz.com "#mySQL.out"
Powershell may have saved the output file in UTF-16 format, which Sqlplus does not like.
(You can confirm by creating the exact same file by hand and then comparing it - byte count will be off and in KDiff you'll get message to the effect that the text is equal, but the files are not binary equal).
To fix - you need to do two things: :
Add some blank lines to the top of your SQL commands - Powershell will still write a BOM (Byte Order Mark) there and it looks like it's pretty hard to get it to avoid that - but sqlplus will just go by it, albeit giving an error - but will move on to the rest of your code OK.
And then run this command in powershell before creating your file: $PSDefaultParameterValues['Out-File:Encoding'] = 'utf8'
See Changing PowerShell's default output encoding to UTF-8
I received this error:
SP2-0042: unknown command " ■S" - rest of line ignored.
and this fixed that - or at least I was able to run it. You can also just cut and past it from one window into another using Notepad++ and that will solve the BOM and encoding issue.
Update Problem Solved. This turned out being "not seeing the trees through the forest". I have been using these sql scripts for several years without issue called from a bash script. When I tried converting the bash script to powershell and ran into issues I blamed it on powershell. However; it turned out there was something corrupt in the sql file itself. There were no obvious errors when looking at the file in notepad++ even with show all symbols clicked and it was ANSI format. I determined it was the sql file itself when I manually ran sqlplus from a cmd window I still had the same error I was getting with powershell. I rewrote the script and saved it and the problem was fixed. I should have manually ran the script on day one and I probably could have resolved sooner.
I had the same problem. My issue was caused because the script file was saved as unicode. I don't know if this will help you or not, but here is how I fixed it:
Edit the script with notepad. Click File -> Save As. Change type from Unicode (or whatever) to ANSI, and save.
A couple of suggestions
Try the invoke operator:
&sqlplus system/passwd#mydb #my_sql
Try start-process:
start-process -NoNewWindow -FilePath sqlplus -ArgumentList #"
system/passwd#mydb #my_sql
"#
I had typical problem. The message was:
unknown command "and" - rest of line ignored.
The reason was an empty string in code.
e.g.
select ...
from ...
where ...
[empty string]
and ... < here was an error message
use as following
sqlplus -s system/passwd#mydb "#my_sql";