I'm trying to write my own .tmux.config file and have managed to get most of it working (the file is quite simple). The intention is to have a minicom session running on the right side, whilst simultaneously saving the communication into a file. There is one problem. I define a UART_LOGFILE_NAME variable in my .bashrc file and export it, however, tmux still returns invalid environment variable. Is there something I'm missing?
my .tmux.conf file looks somewhat like this:
new-session -s serial -n console
split-window -h -l 30%
send-keys "sudo minicom rasp.serial -C ${UART_LOGFILE_NAME}"
split-window -v -l 10%
I can't find anything relevant in tmux manual entry except for the GLOBAL AND SESSION ENVIRONMENT. Also, sice I'm using the send-keys command I thought that the .bash_profile and therefore .bashrc files have been sourced before the minicom is launched (I have already managed to get the minicom running without logging and all panes have the UART_LOGFILE_NAME variable correctly defined after when I run tmux without logging of minicom session).
Thank you for your help
Related
The script using the normal command ./<script.sh> in a terminal window works without any problem. It troughs error returned 127 when running a bash script with bind-key:
tmux version 3.3a
bind-key -r i run-shell "tmux neww \<script path\>"
I have also tried the run the script from tmux command prompt using the :shell-run 'path/script/script.sh command it still does nothing.
Could someone explain what could be the issue. I was wondering if it could be related to tmux's default sh shell. The script uses #!/usr/bin/bash and not #!/usr/bin/sh.
The run:shell command still fails when I the script to #!/usr/bin/sh
I have a WSL Ubuntu distro that I've set up so that when I login 4 services start working, including a web API that I can test via Swagger to verify it is up and working.
I'm at the point where what I want to do now is start WSL via a script - that is, launch my distro, have all of the services start, and do it from Python. The problem is I cannot even figure out the correct syntax to get WSL to start from PowerShell in a manner where my services start.
Side note: "services" != systemctl (or similar) calls, but just executing bash CLI commands from either my .bashrc or .profile at login.
I've put the commands to execute in .profile & .bashrc. I've configured it both for root execution and non-root user execution. I've taken the commands out of those 2 files and put it into a script in the Windows file system that I pass in on the start of wsl. And I've put that shell script in the WSL file system as well. Nothing seems to work, and sometimes the distro starts and then stops after about 30 seconds.
Some of the PS CLI commands I've tried:
Start-Job -ScriptBlock{ wsl -d distro -u root }
Start-Job -ScriptBlock{ wsl -d distro -u root 'bash -i -l -c /root/bin/start.sh'
Start-Job -ScriptBlock{ wsl -d distro -u root 'bash -i -l -c .\start.sh'
wsl -d distro -u root -- bash -i -l -c /root/bin/start.sh
wsl -d distro -u root -- bash -i -l -c .\start.sh
wsl -d distro -u root -- /root/bin/start.sh
Permutations of the above that I've tried: replace root with my default login, and turning all of the Start-Job bash options into a comma-separated list of single-quoted strings (Ex: 'bash', '-i', '-l', ... ). Nothing I launch from the CLI will allow me access to the web API that is supposed to be hosted on my distro.
Any advice on what to try next?
Not necessarily an answer here as much as troubleshooting tips which will hopefully lead to an answer:
First, most of the forms that you are using seem to be correct. The only ones that absolutely shouldn't work are those that attempt to run the script from the Windows filesystem.
Make sure that you have a shebang line starting your script. I'm assuming you do, but other readers may come across this as well. For the moment, try this form:
#!/usr/bin/env -S bash -li
That's going to have the same effect as the bash -li you tried -- It will source both both interactive startup files such as ~/.bashrc as well as login profiles such as ~/.bash_profile (and /etc/profile.d/*, etc.).
Note that preferably, you won't need the -li. Best practice would be to move anything necessary for the services over from the startup scripts to your start.sh script, and avoid parsing the profile and rc. I need to go update some of my answers, since I just realized I've been guilty of giving some potentially bad advice ...
Specifically, though, I'm wondering if your interactive Bash config has something truly, well, "interactive" in it that might be preventing the automatic running of the script itself. Again, best practice would be for ~/.bashrc to only hold configuration that is needed for interactive shell sessions.
Make sure the script is set as executable (chmod +x start.sh). Again, I'm assuming this is the case for you.
With a shebang line and an executable script, use something like:
wsl -d distro -u root -e /root/bin/start.sh
The -e tells WSL to launch the script directly. Since it has a shebang line, it will be parsed by Bash. Most of the other forms you use above actually run Bash twice - Once when launching WSL and another when it finds the shebang line in the script.
Try some basic troubleshooting for your script like:
Add set -x to the top (right under the shebang line) to turn on script debugging.
Add a ps -efH at the end to show the processes that are running when the script completes
If needed, resort to quick-and-dirty echo statements to show where things have progressed in the script.
I'm hopeful that the above will at least show you the problem, but if not, add the debugging info that you gain from this to your question, and we can troubleshoot further.
I'm on a Linux machine using screen, and I'm attempting to write a (fairly portable) function which runs a bash function in a new, detached screen session which automatically closes upon completion. I've had some success, but I noticed the following behavior:
If I include the definition of mail_submit() in my ~/.bashrc file, I can run
mail_submit foo
in the terminal, and also I can access the alias in a new screen session:
screen -S test
mail_submit foo
However, the following command does not work:
screen -d -m -S test sh -c 'mail_submit foo'
presumably because sh -c starts a fresh shell that has no knowledge of my ~/.bashrc profile. So, I can use the following fix:
screen -d -m -S test sh -c 'source ~/.bashrc; mail_submit foo'
which does work.
But if I want to wrap this functionality up into a bash alias (which is my ultimate goal here), this will cause a weird self-referential situation.
Question: What is an easy way to either have sh -c know the location of my ~/.bashrc profile, or use a variant of sourcing the file and creating an alias?
EDIT: I could save the shell script in my home directory, and create an alias which runs
screen -d -m -S test bash -c '~/mail_submit.sh $1'
but I'd still be curious to hear other possible fixes.
A default ~/.bashrc contains this ([[ "$-" != *i* ]] && return) little piece of code on top of it (or somewhere else in the upper part). This line will prevent the ~/.bashrc from beeing sourced if the bash shell doesn't run in interactive mode.
You could:
Remove this line
Create a new file which will only contain the alias you need and source that
Create a little bash script instead of an alias and run that
Do you mean screen -d -m -S test bash -c 'mail_submit foo'?
It looks like you're trying to run the command with the shell (sh), and not the bourne again shell (bash), which is the shell interpreter which actually reads the ~/.bashrc profile.
Edit: The .bashrc file is not being sourced by default because screen does not create the bash process as a login shell, which is when the .bashrc file is read. Creating a .screenrc file with the line defshell -bash will create the bash process as a login shell instead, which will then call the .bashrc file.
Ok everyone, here is an issue which bugged me for quite some time now:
I am trying to run a bash script, which stores certain values in variables, and then starts another command in a detached session, so that the script can continue running because the command takes ages to finish. That's all fine and nice, but the problem is that the command which should be run in the detached session contains variables. This is not a problem when using screen as the "session manager" (or whatever you want to call a program doing session management):
read -p "Session name:" sessionname
read -p "Filename:" filename
screen -S "$sessionname" -d -m nano "$filename"
works fine, opening nano in the detached screen as expected. But when i re-attach to the session and close it, my terminal is cleared and sometinmes some of the text from the file is barfed right before my cursor. I realized that this is an issue with how screen works, so i decided to switch to tmux, but now a whole new realm of prblems opens:
tmux new-session -d -s "$sessionname" nano "$filename"
works fine on cygwin, but on my raspberry 2b running raspbian jessie it throws this error:
usage: new-session [-AdDp] [-c start-directory] [-F format] [-n window-name] [-s session-name] [-t tar
get-session] [-x with] [-y height] [command]
and trying tmux ls afterwards to see if anything started gives me this on the raspberry:
failed to connect to server: No such file or directory
while on cygwin, if no sessions are running, it gives me this:
no server running on /tmp/tmux-197609/default
How can it be that tmux on two different plattforms behaves conmpletely different? Have i installed it wrong on the raspberry (sudo apt-get install tmux) ?
I am all out of ideas what might be the problem here, so any help is greatly appreciated. (Sorry for confused spelling & grammar, non-native english speaker here)
There's possible duplicate but it's closed and unanswered.
As I'm using chef for automation, would be nice to automate tmux launch with pre-launched python web server and second window opened. (this is specifically for my development environment). And only way of doing this probably specifying parameters from command line.
Commands which I want to execute are in window with title "daemon":
source bin/activate
cd project
DEBUG=1 python app.py
I'm unable to find which command line parameters allows to pre-execute commands when launching tmux, and also to open more windows on launch.
You want to create a session without attaching to it (using the -d option), so that you can send additional tmux commands to open the second window before actually attaching.
tmux new-session -t mysession -d 'source bin/activate; cd project; DEBUG=1 python app.py'
tmux new-window -t mysession
tmux attach-session -t mysession