I have an Arch Linux Machine inside which I have "containers" like Centos which I normally chroot and work upon from the command line. I setup Pycharm to work on a project that is inside this "container" The "container" was created using LXC, but I normally login using chroot.
There is a problem running the interactive debugger from Pycharm however.
The command that is run to start the interactive debugger from Pycharm is:
/usr/lib/lxc/centos/rootfs/home/virtual-environment/usr/bin/python /home/nishant/packages/pycharm-community/helpers/pydev/pydevconsole.py
ERROR:root:code for hash md5 was not found
I was able to reproduce this problem without Pycharm.
If I chroot to that environment and then do usr/bin/ python -v -c "import hashlib" everything works.
If I execute /usr/lib/lxc/centos/rootfs/home/virtual-environment/usr/bin/python from my main system, the same error comes.
Fundamentally I think the problem is that I am executing the command in a wrong environment. I think Pycharm should not be executing this interpreter directly but instead in a chroot context.
Is it possible to achieve that using Pycharm?
In general, is it possible to execute a chroot command by not
doing a chroot, like setting the LDD path differently or something
like that?
Related
I'm having an issue with WSL2:
$ where b4a
/usr/local/bin/b4a
$ b4a new
/usr/local/bin/b4a: 1: Not: not found
Even though where finds commands, I can't run them. And it's not a PATH issue either:
echo $PATH
/usr/local/sbin:/usr/local/bin:[...]
And b4a isn't the only command with this problem. What could be the cause? My distribution is Debian 10 and host is Windows 10.
Not necessarily a full answer, but hopefully the troubleshooting methods you need to arrive at a solution ...
Note that it doesn't say that the command itself isn't found. For instance, if you run:
# lllllllllll
lllllllllll: command not found
That's truly a command not found. This is different. While I don't (yet) know the exact cause, this seems closer to the issues we might see with improperly quoted paths with spaces in a shell script.
You mention that other commands have this problem -- Is there something in common with the commands that don't work properly? Is it possible that they are all shell scripts?
Try several things to debug:
Start WSL without your startup profile. It's very likely that something (or you) added a line that is causing problems. From PowerShell or CMD:
wsl ~ -e bash --noprofile --norc
b4a
If that works, then there's a problem in one of your startup files that you'll need to debug. Look for anything modifying environment variables without proper quoting, especially the PATH. WSL automatically appends the Windows path to your Linux path to make it easy to run Windows commands, but the fact that almost every Windows path has spaces in it can cause problems for unsuspecting scripters that don't take this corner case into account.
Having a space in a path is fully allowed in Linux, but some scripts just don't handle it properly.
If the command that is failing is a shell script, trying starting it with:
bash -x /usr/local/bin/b4a
Or even start WSL with wsl ~ -e bash -x to see all trace output from the shell.
In this case, you'll be looking for some problem in the script right around where it actually fails.
If all else fails, you can disable WSL's PATH modification via its config file:
sudo -e /etc/wsl.conf
Add the following:
[interop]
appendWindowsPath = false
Then exit Debian, run wsl --shutdown and restart Debian. Try the b4a command again.
If this works, then the problem is almost certainly due to some problem in the PATH quoting in these commands. I don't recommend it as a permanent solution since you will have to type out the full path of Windows applications each time you want to run them.
I haven't been able to find a similar question, but I can't imagine this is an issue that comes up too much.
At my workplace I've decided to switch over to a full Linux experience by using Cygwin, over what I was previously using, Git Bash.
The only slight drawback is that we have a script written in Ruby that deploys changes to our site. I can run this from my Git Bash terminal no problem, but not Cygwin as there doesn't seem to be a Ruby installation on here. I've learned about sending standard output to other terminal windows, but I've only been successful when both terminals have been the same shell.
What I'd like to do is the following:
1. Type a command into Cygwin that opens a Git Bash terminal and automatically runs ./deploy.sh on that Git Bash terminal upon opening.
2. If possible, also pass in an argument in the same command, that the script expects upon running. (In this case it's whether we want to deploy to our staging or production server).
Is this possible? So far I can get what looks to be a Git Bash terminal to open and prompt me for the server, but when I enter it, it does not work. I get an error with regards to a command within the script not being found. Thing is, running this same ./deploy.sh script in a Git Bash terminal that I open myself works perfectly as it always has. The Git Bash terminal that is being opened by Cygwin does not appear to have all of the capabilities of a Git Bash terminal I open 'the normal way'.
The command I am running so far from Cygwin is as follows:
/cygdrive/c/'Program Files'/Git/git-bash.exe "./deploy.sh"
I understand there is probably a way of getting this to work by installing Ruby via Cygwin but I'd like to mess around with my work environment as little as possible in case I somehow affect my ability to deploy my work... and besides, Git Bash definitely runs this script without an issue so I can't see why I would need a duplicate installation.
Many thanks!
I am attempting to install RetroPie as an app on Raspbian Stretch and I am done except for creating a desktop shortcut for it. The problem is that the only way to open RetroPie seems to be running a command in the command line. I can’t do it in terminal because it gives me an error saying that it can’t initialize the window. Is there a way to run a command line command as a shortcut or am I going to have to find another way of doing this?
P.S. Here is the tutorial that I followed to install RetroPie:
https://www.makeuseof.com/tag/install-retropie-app-raspberry-pi/
Probably your shell (on the raspberry) is GNU bash. So read the manual of GNU bash.
You probably want (once) to edit some Bash startup file (such as ~/.bashrc) to define functions and aliases there, and you could add executable shell scripts somewhere in your $PATH. I recommend having a $HOME/bin/ directory containing your scripts and executables, and have $HOME/bin/ early in your $PATH.
I can’t do it in terminal because it gives me an error saying that it can’t initialize the window.
Perhaps you need some display server (such as Xorg or Wayland) running (with a desktop environment or a window manager). You could run Xorg on your PC (on which you could install Linux) and connect to the raspberry using ssh -X then remote applications running on your Raspberry are displayed on your PC. IF your Raspberry is directly connected to a screen (via HDMI) you might run some Xorg server on it.
Is there a way to run a command line command as a shortcut
Yes, by making a shell alias or shell function or shell script. You need to understand how they work and change or create some appropriate file using some source code editor (I recommend GNU emacs, but the choice is yours and you might use any other editor such as vim, gedit, etc...): functions and aliases could be defined in your ~/.bashrc; shell scripts would usually have their own file with a shebang under your $HOME/bin/...
I am working in a virtual environment, trying to start open vm tools in a chroot environment.
I tested with bash and it seems to work fine.
I used ./configure --options --prefix=/home/chroot_env to install the program, then using ldd on vmtoolsd, i copied the corresponding libraries to the /lib directory.
Now when I start chroot /home/chroot_env /bin/vmtoolsd, nothing happens, the chroot returns directly. Launching the same binary in the normal environment does work.
Does someone have an idea why it isn't working, the correct libraries are there, and it works with bash.
EDIT : strace showed that vmtoolsd is trying to access /dev/console, I added mount --bind /dev/ /home/chroot_env/dev/ but it is still failing.
EDIT2 : another strace showed it was looking for another plugin loaded dynamically, i added it and it worked, conclusion strace is great for debugging such issue!
When you run a program and nothing happens, you can always run it with strace in order to see which syscalls are made. This is an easy way to obtain the list of the files (regular or not) that are opened. In your case, check that your program doesn't try to access a file that is not in the chroot.
I have a Perl program that someone else created and I am calling on with CruiseControl. The program calls on Unix Commands using Cygwin. However, everytime that the Perl program calls on a Unix like command with a DOS like address, I get the well known error:
cygwin warning:
MS-DOS style path detected: E:\regression
Preferred POSIX equivalent is: /cygdrive/e/regression
CYGWIN environment variable option "nodosfilewarning" turns off this warning.
Consult the user's guide for more details about POSIX paths:
http://cygwin.com/cygwin-ug-net/using.html#using-pathnames
I have set both the User Variable AND System Variable CYGWIN to nodosfilewarning. This removes the error when I run the program from the command line, but the error still occurs in CruiseControl when called as an automated process from a batch file. I have called on both the batch file from the Desktop AND Command Line and ran as an administrator. Nothing changes.
Other Notes
For purposes of this problem, I don't have access to the Perl Program
I am trying to go back to Cygwin 1.5.*, but since I am using Server 2008, I am encountering compatibility issues
This is occurring on one of the distributed servers, not the main server running the Webdashboard.
I have read somewhere that this issue may stem from a different user calling on CruiseControl, but the issue should have been solved by setting this as an ENV System variable
Is it possible to modify the registery to set the ENV variables?
Thank you in advance
The way I do it is like this
printf 'export CYGWIN=nodosfilewarning' >> ~/.bash_profile
If CruiseControl is connecting to the server via ssh, reinstall sshd and explicitly include nodosfilewarning when prompted for the CYGWIN environment variable during the install.
Re-installing with modified environment will work but if you don't want to or cannot re-install, an alternative is to change the registry instead of re-installing the service.
See: CYGWIN windows cygrunsrv sshd server and MS-DOS style path detected