If I vagrant ssh with windows cmd, I get a nice command prompt, like that:
vagrant#homestead:~$ echo foo
vagrant#homestead:~$ foo
But with cygwin and mintty, I have no prompt at all:
echo foo
foo
I see it has to do with "pseudo-tty allocation".
With cygwin and mintty, I can have my prompt with this :
vagrant ssh -- -t -t
How can I change cygwin and mintty so that I don't have to tell the -t ?
About the ssh -t option :
"Force pseudo-tty allocation. This can be used to execute arbi-
trary screen-based programs on a remote machine, which can be
very useful, e.g., when implementing menu services. Multiple -t
options force tty allocation, even if ssh has no local tty."
I had the same problem with and the solution was to set the VAGRANT_PREFER_SYSTEM_BIN environment variable to get vagrant to use your normal ssh executable.
You can do:
VAGRANT_PREFER_SYSTEM_BIN=1 vagrant ssh
or put this into your .bash_profile:
export VAGRANT_PREFER_SYSTEM_BIN=1
Reference: https://github.com/hashicorp/vagrant/issues/9143#issuecomment-343311263
I run in the same problem described above. But only on one of three PCs. But as a workaround I am doing:
# save the config to a file
vagrant ssh-config > vagrant-ssh
# run ssh with the file.
ssh -F vagrant-ssh default
From an answer of How to ssh to vagrant without actually running "vagrant ssh"?
In this case I am getting the prompt and what's more important also history cycling and ctrl-c etc. are working properly.
Vagrant is a windows program managing Virtual machine
https://www.vagrantup.com/intro/index.html
as such it does not well interface with the pseudo tty
structure used by cygwin programs.
Read for reference on similar issues with a lot of other windows program
https://github.com/mintty/mintty/issues/56
Mintty is a Cygwin program. It expect interactive program running inside it to use the cygwin tty functionality for interactive behaviour.
Running Vagrant from Bash in Windows CMD, make CMD the terminal control so Vagrant has no problem in the interactive behaviour.
I do not see the need to run Vagrant inside Cygwin
Since vagrant is windows-based, I use ConEmu instead of cygwin's shell (mintty)
choco install conemu via chocolatey and it works
General solution is to teach vagrant to use ssh, compatible with preferred terminal. Like Cygwin ssh+mintty.
Modern Vagrant (v2.1.2) has VAGRANT_PREFER_SYSTEM_BIN=1 by default on Windows.
To troubleshoot issue:
VAGRANT_LOG=info vagrant ssh
In v2.1.2 they broke Cygwin support. See my bug report with hack to lib/vagrant/util/ssh.rb to make it work.
I have been working through some i2c examples. Plugging it all together and I find that I need to install the i2c-tools package, then use raspi-config to enable the I2C system.
The wiringPi gpio command has a shortcut to the i2cdetect command and running it gives
Before 3 weeks everything working properly, detected 68. I didn't understand what is the problem !!! Can anyone one help me to solve this issue.
The I2C bus allows multiple devices to be connected to your Raspberry Pi, each with a unique address, that can often be set by changing jumper settings on the module. It is very useful to be able to see which devices are connected to your Pi as a way of making sure everything is working.
To do this, it is worth running the following commands in the Terminal to install the i2c-tools utility.
sudo apt-get install -y python-smbus
sudo apt-get install -y i2c-tools
If you're not using a modern Raspbian or you want to do it by hand, you can! Open LXTerminal or console or ssh and enter the following command:
sudo nano /etc/modules
and add these two lines to the end of the file:
i2c-bcm2708
i2c-dev
Then save the file with Control-X Y
Depending on your distribution, you may also have a file called /etc/modprobe.d/raspi-blacklist.conf
If you do not have this file then there is nothing to do, however, if you do have this file, you need to edit it and comment out the lines below:
blacklist spi-bcm2708
blacklist i2c-bcm2708
.. by putting a # in front of them.
Open an editor on the file by typing:
sudo nano /etc/modprobe.d/raspi-blacklist.conf
If you are running a recent Raspberry Pi (3.18 kernel or higher) you will also need to update the /boot/config.txt file. Edit it with sudo nano /boot/config.txt and add the text
dtparam=i2c1=on
dtparam=i2c_arm=on
at the bottom. note that the "1" in "i2c1" is a one not an L!
Once this is all done, reboot!
Now when you log in you can type the following command to see all the connected devices
sudo i2cdetect -y 1
Note that if you are using one of the very first Raspberry Pis (a 256MB Raspberry Pi Model B) then you will need to change the command to:
sudo i2cdetect -y 0
Try sudo i2cdetect -y 1 or sudo i2cdetect -y 0 (if you using old Raspberry Pi) and run it on root. Open terminal and run command sudo su, then run sudo i2cdetect -y 1
I ran sudo -s in the OSX terminal and now it is defaulted to running as root.
Is there a way to undo this?
On Unix Type operating systems, all you have to do is type in the exit command this should exit root and return to the user you were currently running under before entering the command.
You can also hit Command+D and that should return you to the user you were running as before the command as well.
Overview
I'm attempting to get XQuartz to work on OSX so I can do X11 forwarding via Docker. I'm following the instructions here. I believe my question may be answered by just the first part, but just in case (to avoid the XY problem), I've provided the second part as well.
Installation
I've installed it via homebrew, via brew cask install xquartz. Then I open -a XQuartz to start it.
Local xterms
Testing it out, if I try to open an xterm, it does not work:
MacBook-Pro:opencv-gui csaftoiu$ xterm
xterm: Xt error: Can't open display: /private/tmp/com.apple.launchd.3wncZULdXC/org.macosforge.xquartz:0
The pseudo-file exists, though:
MacBook-Pro:opencv-gui csaftoiu$ echo $DISPLAY
/private/tmp/com.apple.launchd.3wncZULdXC/org.macosforge.xquartz:0
MacBook-Pro:opencv-gui csaftoiu$ ls -alh $DISPLAY
srw-rw-rw- 1 csaftoiu wheel 0B May 6 21:12 /private/tmp/com.apple.launchd.3wncZULdXC/org.macosforge.xquartz:0
I can open an xterm via XQuartz. Then:
bash-3.2$ echo $DISPLAY
:0
This value works from a regular OSX too:
$ DISPLAY=:0 xterm
# opens xterm, waits for it to finish
$
The following do not work though, not sure why based on the answer here:
xterm: Xt error: Can't open display: localhost:0
MacBook-Pro:opencv-gui csaftoiu$ DISPLAY=127.0.0.1:0 xterm
xterm: Xt error: Can't open display: 127.0.0.1:0
MacBook-Pro:opencv-gui csaftoiu$ DISPLAY=`ipconfig getifaddr en0`:0 xterm
xterm: Xt error: Can't open display: 192.168.1.15:0
Note that xinit does work for some reason:
$ xinit
xinit: XFree86_VT property unexpectedly has 0 items instead of 1
# opens xterm, waits for it to finish
xinit: connection to X server lost
waiting for X server to shut down
Question 1: What is XQuartz actually listening on?
Docker Forwarding with socat
In any case, moving on, this socat command does not work:
MacBook-Pro:opencv-gui csaftoiu$ socat TCP-LISTEN:6000,reuseaddr,fork UNIX-CLIENT:\"$DISPLAY\"
Running that, from another window I do:
MacBook-Pro:opencv-gui csaftoiu$ docker run --rm -it -e DISPLAY=`ipconfig getifaddr en0`:0 ubuntu:14.04 bash
root#912eec31b8cb:/# apt-get update && apt-get install xterm
... such install, wow ...
root#912eec31b8cb:/# xterm
Warning: This program is an suid-root program or is being run by the root user.
The full text of the error or warning message cannot be safely formatted
in this environment. You may get a more descriptive message by running the
program as a non-root user or by removing the suid bit on the executable.
xterm: Xt error: Can't open display: %s
root#912eec31b8cb:/# echo $DISPLAY
192.168.1.15:0
From the socat window I get:
2016/06/14 21:08:15 socat[24289] E connect(5, LEN=68 AF=1 "/private/tmp/com.apple.launchd.3wncZULdXC/org.macosforge.xquartz:0", 68): Connection refused
I can't use the DISPLAY variable that works, either:
MacBook-Pro:opencv-gui csaftoiu$ socat TCP-LISTEN:6000,reuseaddr,fork UNIX-CLIENT:\":0\"
2016/06/14 21:09:43 socat[24309] E connect(5, LEN=4 AF=1 ":0", 4): No such file or directory
Now, this is not a UNIX-CLIENT IP. But, I don't know what DISPLAY=:0 is connecting to. It's certainly not port 6000 since that's the port it used to be listening on. If I change it to 6005, to forward to 6000, and make the Docker container DISPLAY be $(ipconfig getifaddr en0):5 instead, then the connection is of course refused:
$ socat TCP-LISTEN:6005,reuseaddr,fork TCP:localhost:6000
2016/06/14 21:20:32 socat[25379] E connect(8, LEN=16 AF=2 127.0.0.1:6000, 16): Connection refused
Question 2: How to proceed from here?
I hadn't restarted after re-installing XQuartz. I restarted, and now it works. :).
Dockerized UI Apps in Docker for Desktop MacOS 2018+. Updated in in 2021.
Went through all the pain to get the simplest version possible that does not depend on checking port, ip, etc... Here it is.
Running version XQuartz 2.7.11 (xorg-server 1.18.4)
Docker version docker version 18.06.1-ce
Make sure to install XQuartz (Updated with 2021 change)
$ brew install socat
$ brew install --cask xquartz
Don't forget to close logout and log back in.
ATTENTION: At this point, make sure to reboot your host (MacOS for instance). The following error is related to when you don't: E connect(5, LEN=2 AF=1 "<anon>", 2): Invalid argument
$ socat TCP-LISTEN:6000,reuseaddr,fork UNIX-CLIENT:\"$DISPLAY\"
2021/04/04 17:28:58 socat[40606] E connect(5, LEN=2 AF=1 "<anon>", 2): Invalid argument
Instructions
You will need at 2 terminals open: one for the socat with the display and the other for running the UI container.
1. Close any 6000
On a new terminal, verify if there's anything running on port 6000
$ lsof -i TCP:6000
$
If there is anything, just kill the process
2. Close any 6000
Open a socket on that port and keep the terminal open
$ socat TCP-LISTEN:6000,reuseaddr,fork UNIX-CLIENT:\"$DISPLAY\"
3. Verify 6000 is open
In a new terminal, verify if it is opened
$ lsof -i TCP:6000
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
socat 29298 marcellodesales 5u IPv4 0xe21e43ca9d99bf1d 0t0 TCP *:6000 (LISTEN)
4. Build and Run simple UI App
$ cat Dockerfile.eyes
FROM debian:latest
RUN apt-get update && apt-get install -y x11-apps
RUN rm -rf /tmp/* /usr/share/doc/* /usr/share/info/* /var/tmp/*
RUN useradd -ms /bin/bash user
ENV DISPLAY :0
USER user
ENTRYPOINT ["/bin/sh", "-c", "$0 \"$#\"", "xeyes"]
$ docker build -t eyes -f Dockerfile.eyes .
The magic happens using the variables from Docker. Just using the -e DISPLAY=docker.for.mac.host.internal:0 did the trick, as it it will point to the internal IP address and provide that to the docker image. The port forward will do its magic.
$ docker run -ti --rm -e DISPLAY=docker.for.mac.host.internal:0 eyes
I noticed that at this point XQuartz is opened on it own to the same port
$ lsof -i TCP:6000
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
socat 29298 marcellodesales 5u IPv4 0xe21e43ca9d99bf1d 0t0 TCP *:6000 (LISTEN)
X11.bin 29462 marcellodesales 8u IPv6 0xe21e43ca7cdb1135 0t0 TCP *:6000 (LISTEN)
5. Profit and run more apps
$ docker run -e DISPLAY=docker.for.mac.host.internal:0 jess/tor-browser
$ docker run -e DISPLAY=docker.for.mac.host.internal:0 batmat/docker-eclipse
I needed to quit Terminal and then relaunch it in order to get it to work.
For OS X 10.6.3 and later, per XQuartz 2.7.11 instructions:
If this is your first time installing XQuartz, you may wish to logout and log back in. This will update your DISPLAY environment variable to point to XQuartz.app rather than X11.app. If you would prefer to keep using X11.app as your default server (you can still launch XQuartz.app manually), you’ll want to disable /Library/LaunchAgents/org.macosforge.xquartz.startx.plist using launchctl(1).
After installing XQuartz 2.7.11 on my macOS High Sierra, logging out of my Mac and logging in again was enough for this to work via my MacOS Terminal. However, you may avoid having to logout and log in by opening the XQuartz Terminal application (XQuartz > Applications > Terminal), and running your X application from there. For example:
and then
bash-3.2$ xclock &
This answer is possibly limited to MacOS/Monterey.
After running XQuartz and setting the Preferences/Security/"Allow connections from network clients" option, you must restart XQuartz. (It may be the case that after install, you must logoff/logon again, but I found that merely restarting XQuartz was sufficient.) Afterwards, when XQuartz is running again, you should see it listening on port 6000:
lsof -i TCP:6000
Before this restart step, only DISPLAY=:0 or the default file-based socket worked for me. After this step, I could then do
export DISPLAY=localhost:0
and xterm, xhost, etc worked fine.
To use with docker, I used:
xhost +localhost
DISPLAY=docker.for.mac.host.internal:0
docker run -e DISPLAY=$DISPLAY -v /tmp/X11-unix:/tmp/.X11-unix
I used this code will help you in macos Big sur
https://apple.stackexchange.com/questions/411619/how-to-make-dia-which-uses-x11-xquartz-work
export DISPLAY=:0 # Fixes the "cannot open display".
export LANG="en_US.UTF-8" # Fixes the annoying Xterm window opening.
exec "$CWD/dia-bin" --integrated
I am wanting to detect in a shell script if a command I am going to run via sudo can in fact run via sudo. On newer versions of sudo I can do sudo -l "command" and this gives me exactly the result I want.
However, some of the systems have an old version of sudo in which -l "Command" isn't available. Another way I was thinking about doing it was to just try running the command then see if sudo prompted for the password. However, I do not see an easy way to do this as sudo writes the password prompt to the TTY and not via stdout.
Does anyone else know of a straight forward way to do this?
I should also mention "expect" doesn't seem to be available on the systems with the older sudo revisions, either.
Just for reference the "difficult" version of sudo appears to version 1.6.8
On Linux, on (at least) Debian-like systems, you can have a look at /etc/sudoers (and the optional /etc/sudoers.d/* files, if created, and included in the main /etc/sudoers) that give (among others)
the search path to where (which dir) a command can be issued
the sudo user (root) privileges
groups who can use sudo and their privileges
This is the sudoers man page for more information.
if you're only wanting to check that a password is required to run a command then you should be able to run:
$ sudo -n <command>
E.g.
$ sudo -n echo
sudo: sorry, a password is required to run sudo