Seeing some weird behavior in iPython that appears to depend on how it's launched. When launched in terminal, certain shell commands work (pwd), but both 'ls' and '!ls' error out - see below for a § of the OSError Traceback.
When launched with the Qtconsole: "ipython qtconsole --pylab=inline", all appears to be well.
[Additional information: the shell commands work fine when ipython is launched as a notebook.]
[Additional information #2: "iptest core" generates 4 errors - all of which are related to File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/subprocess.py"]
Any suggestions? Thanks! Running Python 2.7.5, IPython 2.1.0, Mac OSX Mavericks.
...
/Library/Python/2.7/site-packages/IPython/core/interactiveshell.pyc in system_raw(self, cmd)
2277 cmd = py3compat.unicode_to_str(cmd)
2278 # Call the cmd using the OS shell, instead of the default /bin/sh, if set.
-> 2279 ec = subprocess.call(cmd, shell=True, executable=os.environ.get('SHELL', None))
2280 # exit code is positive for program failure, or negative for
2281 # terminating signal number.
OSError: [Errno 2] No such file or directory
I can't make sense of all of your symptoms, but the error [Errno 2] message suggests that your SHELL environment variable contains a value that doesn't point to an existing shell executable.
Normally, SHELL contains the full path to your default shell's executable, e.g., /bin/bash.
Things you can try:
Check the output of echo $SHELL and make sure it contains the full path of your default shell's executable.
Invoke ipython with an explicit SHELL value and see if the problem goes away: SHELL=/bin/bash ipython.
pwd doesn't actually invoke a shell instance, so that's why you don't see an error.
By contrast, ls (indirectly) and !ls (directly) do.
I'm running the same versions, and iptest core fails on my machine too, although differently (ImportError: No module named nose.plugins.builtin) - however, at least in my case it seems unrelated to running shells from ipython, which works fine.
Related
I'm using the most recent VScode on Ubuntu 22.10 and experiencing the following issues while opening ZSH and BASH shells in the integrated terminal. The standard Ubuntu terminal works without errors.
After starting a ZSH integrated terminal:
compdump:138: command not found: mv
/home/user/.oh-my-zsh/oh-my-zsh.sh:56: command not found: mkdir
/home/user/.oh-my-zsh/tools/check_for_upgrade.sh:29: command not found: git
/home/user/.oh-my-zsh/oh-my-zsh.sh:115: command not found: rm
getent:6: command not found: grep
_p9k_init_cacheable:59: command not found: uname
_p9k_init_cacheable:61: command not found: uname
BASH
Command 'uname' is available in the following places
* /bin/uname
* /usr/bin/uname
The command could not be located because '/bin:/usr/bin' is not included in the PATH environment variable.
uname: command not found
Just several hours before, it worked just fine. Then I tried to set up Remote SSH to another Linux machine (Fedora 36, with the same sort of errors I was also unable to resolve by googling).
Using the #modified keyword in Settings, I ensured that no unexpected changes had been made. The PATH is the same as in the fully operational standard terminal.
Wondering what could be the issue.
UPDATES.
PATH variable:
/usr/local/cuda-11.7/bin:/home/user/.conda/envs/env/bin:$PATH
The problem.
Unlike the complete PATH expansion in the standard terminal, PATH was expanded partially (omitting /usr/bin, etc.) in the integrated terminal.
Based on this error,
The command could not be located because '/bin:/usr/bin' is not included in the PATH environment variable.
I suggest you run,
export PATH="/usr/bin:$PATH"
To add /bin:/usr/bin to your PATH
Having :$PATH in your PATH means that the sheell will add the variable $PATH to the end of your PATH
The cause of the issue the following configuration from the User settings:
terminal.integrated.env.linux": {
"PYTHONPATH": "/media/user:/media/user/common:$PYTHONPATH",
"PATH": "/media/user:/media/user/common:$PATH"
}
While the PYTHONPATH variable is expanded properly in the integrated terminal, the PATH is expanded partially to something shown in the UPDATES section of the question. To build on top of the answer by #Orion447, looking for any potential place where PATH could get corrupted is the approach that likely solves the problem.
I am creating an installation using InstallShield 2018 in windows 10. I need to execute a script file (.sh) in Ubuntu from a function in Installscript. I tried the following but it did not work:
szCmdPath = "C:\\Users\\Admin\\AppData\\Local\\Microsoft\\WindowsApps\\Ubuntu.exe";
szCmdLine = ". /mnt/d/test.sh";
LaunchAppAndWait( szCmdPath, szCmdLine, WAIT);
However I can execute the exact same file in Ubuntu Terminal and it works great. I did turn on Window sub system for Linux and install Ubuntu on windows. Why is this happening? Why can I run cmd.exe from installscript but not Ubuntu?
Thank you in advance.
EDIT 1: if I pass an empty string as parameter, Ubuntu is start and waits for my input commands. But when I pass the path to my script file, nothing happened except a flash of the terminal console before my installation goes on running.
From my reading, wsl and ubuntu differ slightly. It looks like wsl is a bit magical and occasionally similar to bash -c or ubuntu -c, whereas you can consider Ubuntu.exe as somewhat equivalent to /bin/bash.
If you try to run /bin/bash . /mnt/d/test.sh from a bash prompt, things don't go well. So the correct approach will depend on the contents of your script and what you need to happen. I think one of the following options are the most likely:
remove . from your command; instead run ...\Ubuntu.exe /mnt/d/test.sh
add -c to your command; instead run ...\Ubuntu.exe -c . /mnt/d/test.sh
Note that %LOCALAPPDATA%\Microsoft\WindowsApps\Ubuntu.exe is a special file (zero bytes), so it's also plausible that it needs some special handling. For instance, maybe it requires a 64-bit caller. If that's the case, you may need to wrap it in a call through a 64-bit cmd prompt. My quick tests don't show this as likely, however, so I think it will work without this extra indirection.
I recently switched to fish shell from zsh and I have been encountering errors when I update my nvim config file
It appears the error comes when checking for the $TMUX environmet variable in a conditional statement. I added set shell=/bin/bash to the config solve the problem reloading vim but the error persisted.
Here is the error from when I try source ~/.config/nvim/init.vim:
~/.config/nvim/init.vim (line 99): Illegal command name “exists("$TMUX")”
if exists("$TMUX")
^
from sourcing file ~/.config/nvim/init.vim
called on line 1 of file -
in function “sv”
called on standard input
source: Error while reading file “/home/slick/.config/nvim/init.vim”
Confused because I am not very solid with vimscript and am not sure which language the conditional statement in the nvim config should be written in or how to resolve this error.
source ~/.config/nvim/init.vim
is a Neovim command, not a shell command. There's no reason whatsoever to expect your shell to understand Neovim's scripting language so running that command in your shell makes no sense at all.
Run it in Neovim, not in your shell.
Vim scripts that run external commands expect a POSIX compatible shell. Fish is explicitly not POSIX compatible. Add set shell=/bin/sh (or some other POSIX shell) to your vimrc.
I followed instructions on this page to change the profile of the Mac terminal when I'm running SSH. The short explanation is that it puts a wrapper script in /usr/local/bin that changes the colour then calls /usr/bin/ssh. When I call this script with the full path it works perfectly, but when I call 'ssh', it appears to use the regular application without the wrapper script.
When I call 'which ssh', the result is '/usr/local/bin/ssh'. My PATH variable is '/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin:/Library/TeX/texbin', which looks fine for me. The wrapper script has executable permissions ('-rwxr-xr-x ').
What am I missing? Why would the regular ssh be called rather than than the wrapper script, given the 'which' command points to the one that I want?
You forgot to clear bash's program location cache.
hash -d ssh
I rarely touch shell scripts, we have another department who write them, so I have an understanding of writing them but no experience. However they all appear rather useless with my issue.
I am trying to execute some KornShell (ksh) scripts on a windows based machine using Cygwin- we use these to launch our Oracle WebLogic servers, now it simply will not execute. I used to be able to execute these exact same scripts fine on my old machine.
Now I have narrowed this down to the fact the 'magic number' or whatever it is at the start of the script where it specifies the script interpreter path:
i.e.:
#!/bin/ksh
if I change it to execute as a simple bash it works i.e:
#!/bin/sh
I went through checking the packages installed for cygwin - now the shells I installed are:
mksh MirdBSD KornShell
bash the bourne again shell
zsh z shell
Should I expect to see a ksh.exe in my cygwin/bin directory? there is a system file 'ksh' which I was making an assume somehow associates it with one of the other shell exes, like mksh.exe
I understand my explanation may well be naff. But that being said, any help would be very much appreciated.
Thanks.
I believe the MirBSD korn shell is called mksh. You can verify this and look for the correct path by typing
% which mksh
% which ksh
or if you have no which,
% type -p mksh
% type -p ksh
or if that fails too, check /etc/shells which should list all valid shells on a system:
% grep ksh /etc/shells
You need to put the full path after the #! line. It will probably be /bin/mksh, so your line needs to look like:
#!/bin/mksh
You've probably fixed it by now, but the answer was no, your Cygwin does not (yet) know about ksh.
I solved this problem by launching the cygwin setup in command-line mode with the -P ksh attribute (as described in http://www.ehow.com/how_8611406_install-ksh-cygwin.html).
You can run a ksh using a bat file
C:\cygwin\bin\dos2unix kshfilename.ksh
C:\cygwin\bin\bash kshfilename.ksh
Running a shell script through Cygwin on Windows
Install KornShell (ksh) into Cygwin by the following process:
Download: ksh.2012-08-06.cygwin.i386.gz
Install ksh via Cygwin setup.
Execture Cygwin setup.exe
Choose: Install from Local Directory
Select the ksh.2012-08-06.cygwin.i386.gz as the Local Package Directory.
Complete Cygwin setup.
Restart Cygwin.