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.
So I have two WSLs (version 2). Kali and Ubuntu. The code command works in Kali but Ubuntu says Command not found. Since it works in WSL, CMD and PowerShell, it is there in PATH variables. Any help?
edit: Ubuntu doesn't read VS Code in PATH variables, while Kali does. I opened the Environment Variables Wizard. VS Code is there.
In a "normal" case, like you are seeing in your Kali instance, WSL's init appends the Windows path to your Linux path. There are two things that I can think of that would cause that to not be happening correctly under your Ubuntu instance:
You or a script that you ran in Ubuntu modified your shell's startup files (assuming Bash, typically ~/.bashrc or ~/.profile) to edit the PATH, possibly removing the Windows elements, or at least the VSCode element.
Try running that instance without any Bash startup files (from PowerShell or CMD) with:
PS> wsl -d Ubuntu -e bash --noprofile --norc
and then try code .. This, of course, assumes that your Ubuntu instance is named Ubuntu. If it's named something else (wsl -l) then edit the -d Ubuntu as needed. You might also try launching it as wsl -d Ubuntu -e sh -c 'code .'
If that works, examine your startup files for any modifications to PATH.
Less likely (because you should know if you did this one), is that you can disable the WSL feature that appends the Windows PATH in a particular distribution/instance. Check for the existence of a /etc/wsl.conf file -- If it exists, the line appendWindowsPath=false would cause the behavior that you are seeing as well. Simply change the offending setting to true. Exit your Ubuntu instance, run wsl --terminate Ubuntu (again, substituting the correct distro name) and then restart. Check your PATH and try code . again then.
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.
Using PostgreSQL when I connect to a db using \c testdb inside PostgreSQL Database SQL Prompt. I successfully connect to the db but getting the following warning:
postgres-# \c testdb
WARNING: Console code page (437) differs from Windows code page (1252)
8-bit characters might not work correctly. See psql reference
page "Notes for Windows users" for details.
You are now connected to database "testdb" as user "postgres".
testdb-#
What does this warning mean? How to resolve it?
From the psql documentation:
psql is built as a "console application". Since the Windows console
windows use a different encoding than the rest of the system, you must
take special care when using 8-bit characters within psql. If psql
detects a problematic console code page, it will warn you at startup.
To change the console code page, two things are necessary:
Set the code page by entering cmd.exe /c chcp 1252. (1252 is a code
page that is appropriate for German; replace it with your value.) If
you are using Cygwin, you can put this command in /etc/profile.
So to remove that warning you need to execute chcp 1252 before you enterpsql. Using chcp without parameters gives you the current codepage.
The default codepage for CMD.exe is different than the default for postgres... To change for CMD.exe using the REGISTRY try this:
Start -> Run -> regedit
Go to [HKEY_LOCAL_MACHINE\Software\Microsoft\Command Processor]
Add new string value named "Autorun" with value "chcp 1252"
Then reopen CMD.exe
To make it even more obvious, the file to which #user3423801 is adding the line
cmd.exe /c chcp 1252
is in the scripts directory where you installed Postgre.
For example, in my case it is
C:\Program Files\PostgreSQL\9.3\scripts\runpsql.bat
Open cmd.exe and run regedit.
Go to Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Command Processor
New a string value named: Autorun and change the value to be chcp 1252
Done.
Reference: https://stackoverflow.com/a/30100565/8396969
Please don't assume that Unix fixes work for Windows Users. For Windows 10, and PostgreSQL 12, combining the answers by "user3423801" and "numbers longer" worked for me. (The Windows Registry hack would not work. I did not try rebooting yet.) It is better to fix it in the PSQL startup script anyway.
The file location C:\Program Files\PostgreSQL\12\scripts contains the file runpsql.bat, into which you must insert the cmd.exe /c chcp 1252 command in the right location. So the top of your edited file should look like the 5 or 6 lines below.
#echo off
REM Copyright (c) 2012-2014, EnterpriseDB Corporation. All rights reserved
REM PostgreSQL server psql runner script for Windows
cmd.exe /c chcp 1252
SET server=localhost
SET /P server="Server [%server%]: "
The answer of dvdgsng is correct but with code example is more obviously.
#echo off
REM Copyright (c) 2012-2014, EnterpriseDB Corporation. All rights reserved
REM PostgreSQL server psql runner script for Windows
cmd.exe /c chcp 1252
SET server=localhost
SET /P server="Server [%server%]: "
Or you can simply type cmd.exe /c chcp 1252 in the Command Prompt window.
you just go to the power-shell or cmd.exe and type the command chcp 1252 or whatever the page number it wants "the one that is the windows code page". If the problem still persists, just open the console properties 'By clicking the power shell icon on the top left of the console window and choosing properties from the drop-down menu' and change the font to "Lucida Console". It worked for me, But you have to open power-shell as an Administrator.
The answers above are okay, but don't mention anywhere that Windows 1252 encoding is good for English language versions of Windows AND the other Western European Languages. This completes the answer for those people who may get confused about the aforementioned application to German language encoding. Yes it works for English without umlauts and other special characters needed for German, Spanish, French, Italian, Romanian, Hungarian, etc.
https://en.m.wikipedia.org/wiki/Windows-1252
What is Windows 1252 encoding?
Windows-1252 or CP-1252 (code page 1252) is a single-byte character encoding of the Latin alphabet, used by default in the legacy components of Microsoft Windows for English and some other Western languages (other languages use different default encodings).
After much digging for an answer that made sense to me, I found this help email chain at the PostgreSQL site which basically says to run chcp 1252 from inside an open command window.
I was then able to run my PostgreSQL commands without the code warning.
NOTE: this change does not persist so you have to run it every time you open a new command window where you plan to use PostgreSQL commands.
For Postgres 11
"WARNING: Console code page (437) differs from Windows code page
(1252)
8-bit characters might not work correctly. See psql reference
page "Notes for Windows users" for details."
If you aren't an administrator on your machine
Add a line "chcp 1252" to the pg_env.bat script found in the base directory of your postgres installation.'
i.e. "C:\Program Files\PostgreSQL\11"
If you are and Administrator on your machine
you can modify the registry to run the line everytime you run "cmd.exe" as mentioned above.
I couldn't figure out how to set it for Cygwin globally. This seemed to work though in my bash script
#!/bin/bash
cmd.exe /c chcp 1252 && psql -h myserver.postgres.database.azure.com -U myuser#prod-au -d mydatabase
Basically, set your console application encoding from 8-bit to utf-8 Windows 1252.
For git bash users
run the command chcp.com 1252 before running postgres
chcp is a windows console command, so to execute it on git bash you might need to add .com
git bash can't extend chcp to a full executable on its own, so you need to type the full command.
here
On the terminal screen go to the following directory;
C:\Program Files\PostgreSQL\14\bin
note: whichever database version you are using, go to the bin folder of the db version file.
Before creating a user or accessing the database user, you must write the following code;
cmd.exe /c chcp 1252
Typing this command on regular cmd.exe or cygwin termal gives me results as expected:
$ ack hello
(I have ack.bat that execute ack.pl in my PATH)
However, when I run the same command from either shell or eshell in Emacs, it gives me this error:
c:\Users\Martin>"C:\cygwin\bin\perl" /cygdrive/c/Users/Martin/Desktop/ack.pl hello
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LC_ALL = (unset),
LANG = "ENU"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
I tried to fix it by SETENV both variable to en_US.UTF-8 but when I run it again, it gave me no result but froze.
Update: I have finally found the solution to this problem. All I need was to add < NUL to the end of the command since it parse Linux style NULL DEVICE as default.
Now if I type in this:
ack hello < NUL
It'll give me results as expected.
This problem doesn't have to do with ack per se, but pearl, the language Ack is written in. What perl reports is that your environment where you are running emacs does not have the locale settings set. Add the following lines to whatever environment you're running emacs in:
export LC_CTYPE=en_US.UTF-8
export LC_ALL=en_US.UTF-8
Note: running ack hello < NUL only masks the problem, it doesn't resolve it.