When I run urxvt -cd "/absolute/path" to start a terminal in a directory, it doesn't load my user zsh settings, it only loads the global ones in /etc.
Here's some context: Running latest stable versions of rxvt-unicode and zsh (on Arch Linux). I've got ZDOTDIR=~/.zsh in case that makes a difference (but I doubt it, since I tried symlinking ~/.zshrc to ~/.zsh/.zshrc.) If I just run urxvt then it works fine, but it's with the -cd flag that it messes up.
The reason I'm trying to do this is to start a terminal in the current location from Thunar AND have it read my user zsh configuration file. So if you know another way of doing this then that will work too.
Try adding -ls to its options to run it as login shell, like:
urxvt -ls -cd "/absolute/path"
Otherwise it will spawn a subshell. If that doesn't work for you, it still possible to use:
urxvt -e /where/is/your/zsh -i -l -c "cd /where/you/want/it"
Or (regarding the Thunar custom action):
urxvt -cd %f -e /where/is/your/zsh -i -l
Related
My current WSL2 + ConEmu + bash/zsh setup works as expected.
I have some aliases set up in my .zshrc:
//.zshrc
alias mycommand1="[does some stuff]"
alias mycommand2="[does other stuff]"
What I want to achieve is to have a ConEmu startup Task that would run mycommand1 and mycommand2 in two separate tabs, and then leave these tabs open.
This requires ConEmu to load up WSL+bash+zsh, and then run the command.
As per the docs, my default Task currently runs native wsl.exe:
// {Bash::bash} Task commands
%windir%\system32\wsl.exe -cur_console:pm:/mnt --distribution Ubuntu-20.04
And, after carefully reading all the docs (1, 2, 3) and spending a fair amount of time on fiddling with params, I was only able to produce following attempts:
%windir%\system32\wsl.exe --distribution Ubuntu-20.04 -new_console:pm:/mnt -- ls
// logs my Windows User directory and prompts "Press Enter or Esc to exit..."
%windir%\system32\wsl.exe --distribution Ubuntu-20.04 -new_console:pm:/mnt -- mycommand1
// logs "zsh:1: command not found: mycommand1" and prompts "Press Enter or Esc to exit..."
I would appreciate some pointers:
How can I pass a command from wsl.exe that will be run from within the Ubuntu context, with all my bash/zsh configs?
How can I do that from ConEmu Task, ensuring that after running the command the tabs stay open with a regular zsh shell prompt?
Is there anything else I need to know to solve my problem?
Adding this as a second answer in case it works for you (and it very well may).
My (very long) other answer assumes that you need the alias to run in the same subshell instance that continues to run. If you are okay with the alias running, then exec'ing a new shell, then this answer will be much simpler.
Just create a conemu_start.txt (or whatever you want to call it, wherever you want to place it), with the following:
>%windir%\system32\wsl.exe -cur_console:t:"MyCommand1" -cur_console:pm:/mnt ~ --distribution Ubuntu-20.04 --exec zsh -li -c "mycommand1; zsh -li"
>%windir%\system32\wsl.exe -cur_console:t:"MyCommand2" -cur_console:pm:/mnt ~ --distribution Ubuntu-20.04 --exec zsh -li -c "mycommand2; zsh -li"
As with the other answer, in ComEmu, set Settings -> Startup -> Tasks file to this file.
That's it. The -li will cause the shells to be login (which processes .zprofile) and interactive (which processes .zshrc). That way, the aliases get defined, executed, and then another subshell is run to keep the ConEmu tab open.
Short answer:
Create a new startup directory with a new .zshrc that (a) sources the existing profile, and (b) runs aliases based on an environment variable set before starting the shell.
Start each shell (tab) by setting ZDOTDIR, RUN_ALIAS, and execing zsh -li
Run these through the wsl.exe command
Set a ConEmu startup file to run the appropriate commands
Step 1: Launch zsh, run an alias, and keep the session from exiting
Assumptions: I'm going to assume you really do want these to be aliases. If you want to run other arbitrary scripts/commands, you can still do it, but it will require a slight change to the instructions. I've summarized the changes needed in-line below.
There are several techniques you could use to keep the shell running, but the ones suggested in this question require you to either:
Create a nested shell, which is not ideal.
Or modify your existing ~/.zshrc to "special case" a launch with your command. It's a neat trick, but I'm not a fan of changes to the default startup files when they can be avoided. That said, it's much easier. If you want to go this route, I'll add some info at the bottom of this answer on how to do it.
But the ~/.zshrc solution got me thinking. If you want to run any arbitrary command at startup, and yet keep the shell running, the answer is .zshrc.
You just need to have a different .zshrc that you use for the "special case".
bash has the --rcfile option to select the file to run at startup, but the zsh equivalent is a bit trickier, as it involves setting $ZDOTDIR and changing the location from which zsh reads its startup (from this answer).
So to start, let's create a config directory for your "run an alias" config:
mkdir -p ~/.local/share/zsh/startup/run_alias/`
Or wherever you want, of course. Then, in that directory, create the following:
~/.local/share/zsh/startup/run_alias/.zshrc:
if [ -f $HOME/.zshrc ]; then
. $HOME/.zshrc
fi
if [ -v RUN_ALIAS ] && alias | grep -q "^$RUN_ALIAS="; then
eval "$RUN_ALIAS"
fi
unset RUN_ALIAS
unset ZDOTDIR
And ~/.local/share/zsh/startup/run_alias/.zprofile:
if [ -f $HOME/.zprofile ]; then
. $HOME/.zprofile
fi
The conditionals, of course, are optional if you always know that your $HOME/.zsh and .zprofile exist. But better to be safe.
Repeat for mycommand2.
If it's not obvious, this will:
Call your existing $HOME/.zshrc to define the aliases (and anything else in your startup)
Check to make sure the contents of $RUN_ALIAS really is an alias (some added security)
Call the alias defined in the RUN_ALIAS variable
Unset the RUN_ALIAS variable (cleanup)
Unset the special ZDOTDIR so that future subshell invocations will use the files in $HOME.
Have the new .zprofile source the original as well
You can now test this by calling a subshell with:
ZDOTDIR=~/.local/share/zsh/startup/run_alias RUN_ALIAS=mycommand1 zsh -li
But of course, that leaves an extra subshell running ($SHLVL is 2). So, use exec instead:
ZDOTDIR=~/.local/share/zsh/startup/run_alias RUN_ALIAS=mycommand1 exec zsh -li
$SHLVL is now 1, your command/alias should have been executed in the current (and only) shell, and it is still running.
To get that running in WSL, we do need to start an "outer shell" (that is replaced by execing the proper zsh). I tend to use sh for this, like so:
wsl ~ --distribution Ubuntu-20.04 --exec sh -c "ZDOTDIR=`$HOME/.local/share/zsh/startup/run_alias RUN_ALIAS=mycommand1 exec zsh -li" # PowerShell quoted
wsl ~ --distribution Ubuntu-20.04 --exec sh -c "ZDOTDIR=$HOME/.local/share/zsh/startup/run_alias RUN_ALIAS=mycommand1 exec zsh -li" # CMD (and ConEmu) quoted
Side note: My Windows Terminal profiles for wsl actually used to look very similar to this. I've streamlined them a bit, but I still set an environment variable (the title I want for the tab) before starting my shell (fish) and tmux.
Side note #2: My original answer used two separate ZDOTDIR's and corresponding directories. This would still be useful if you wanted to execute different commands (as opposed to aliases). In that case, create additional directories, and point to them by changing the ZDOTDIR. Just put your commands in the modified .zshrc in the corresponding directory.
Run the commands at ConEmu Startup
The easy part. Create a conemu_start.txt anywhere (and any name), really:
>%windir%\system32\wsl.exe -cur_console:t:"MyCommand1" -cur_console:pm:/mnt ~ --distribution Ubuntu-20.04 --exec sh -c "ZDOTDIR=$HOME/.local/share/zsh/startup/run_alias RUN_ALIAS=mycommand1 exec zsh -li"
>%windir%\system32\wsl.exe -cur_console:t:"MyCommand2" -cur_console:pm:/mnt ~ --distribution Ubuntu-20.04 --exec sh -c "ZDOTDIR=$HOME/.local/share/zsh/startup/run_alias RUN_ALIAS=mycommand2 exec zsh -li"
In ComEmu, set Settings -> Startup -> Tasks file to this file.
That should do it. Starting ConEmu should now open two tabs with zsh, one for each of these aliases/commands.
Alternative: Modify existing .zshrc to run an alias based on an environment variable
Add the following to the bottom of ~/.zshrc:
if [ -v RUN_ALIAS ] && alias | grep -q "^$RUN_ALIAS="; then
eval "$RUN_ALIAS"
fi
Test it with:
RUN_ALIAS=mycommand1 exec zsh -li
And then change the conemu_start.txt to:
>%windir%\system32\wsl.exe -cur_console:t:"MyCommand1" -cur_console:pm:/mnt ~ --distribution Ubuntu-20.04 --exec sh -c "RUN_ALIAS=mycommand1 exec zsh -li"
>%windir%\system32\wsl.exe -cur_console:t:"MyCommand2" -cur_console:pm:/mnt ~ --distribution Ubuntu-20.04 --exec sh -c "RUN_ALIAS=mycommand2 exec zsh -li"
Does tcsh support launching itself in a remote directory via an argument?
The setup I am dealing with does not allow me to chdir to the remote directory before invoking tcsh, and I'd like to avoid having to create a .sh file for this workflow.
Here are the available arguments I see for v6.19:
> tcsh --help
tcsh 6.19.00 (Astron) 2015-05-21 (x86_64-unknown-Linux) options wide,nls,dl,al,kan,rh,color,filec
-b file batch mode, read and execute commands from 'file'
-c command run 'command' from next argument
-d load directory stack from '~/.cshdirs'
-Dname[=value] define environment variable `name' to `value' (DomainOS only)
-e exit on any error
-f start faster by ignoring the start-up file
-F use fork() instead of vfork() when spawning (ConvexOS only)
-i interactive, even when input is not from a terminal
-l act as a login shell, must be the only option specified
-m load the start-up file, whether or not owned by effective user
-n file no execute mode, just check syntax of the following `file'
-q accept SIGQUIT for running under a debugger
-s read commands from standard input
-t read one line from standard input
-v echo commands after history substitution
-V like -v but including commands read from the start-up file
-x echo commands immediately before execution
-X like -x but including commands read from the start-up file
--help print this message and exit
--version print the version shell variable and exit
This works, but is suboptimal because it launches two instances of tcsh:
tcsh -c 'cd /tmp && tcsh'
I have incron setup and working, i can see things being logged when files are changed.
I've tried my rsync command separately and that works fine. But when rsync in triggered by incron, nothing happens. i explicitly stated all the paths i could see.
here is my incrontab -e
/home/dir/dir/ IN_MODIFY sudo rsync -pogr -e 'ssh -i /root/.ssh/rsasync1' /home/dir/dir/* root#ipaddress:/home/dir/dir/
i'm working as root right now and executing the command as root. also tried /usr/bin/rsync and that didn't work in addition to sudo rsync etc...
thanks!
Try this in incrontab:
/home/dir/dir/ IN_MODIFY sudo rsync -pogr -e ssh -i /root/.ssh/rsasync1 /home/dir/dir/* root#ipaddress:/home/dir/dir/
In above command I have removed the quotes. Incrontab can not run with Single quote OR double quote.
Remember: Pleas keep the quote while executing in terminal.
I am hoping someone can help me figure out what setting I might need to overwrite. I am working on a Unix terminal server, running a Linux Xterm linux shell. Everytime I use a command like grep "blah" 2> /dev/null at the shell prompt, the command is run as grep "blah" 2 > /dev/null and needless to say the redirection fails.
xterm version is X.Org 6.8.99.903(238)
I can not update or install anything, this is a locked down production server.
Thanks for any help and illumination on the topic, it is making my grep useless at high directory levels with recursion.
That's Bourne shell syntax, and it doesn't work in c-shell.
The best you can do is
( command >stdout_file ) >&stderr_file
Where you get stdout to one file, and stderr to another. Redirecting just stderr is not possible.
In a comment, you say "A minor note, this is csh". That's not a minor note, that's the cause of the problem. xterm is just a terminal emulator, not a shell; all it does is set up a window that provides textual input and output. csh (or bash, or ...) is the shell, the program that interprets the commands you type.
csh has different syntax for redirection, and doesn't let you redirect just stderr. command > file redirects stdout; command >& file redirects both stdout and stderr.
You say the system doesn't have bash, but it does have ksh. I suggest just using ksh; it will be a lot more familiar to you. Both bash and ksh are derived from the old Bourne shell.
All (?) Unix-like systems will have a Bourne-like shell installed as /bin/sh. Even if you're using csh (or tcsh?) as your interactive shell, you can still invoke sh, even in a one-liner. For example:
sh -c 'command 2>/dev/null'
will invoke sh, which in turn will invoke command and redirect just its stderr to /dev/null.
The purpose of an interactive shell is (mostly) to let you use other commands that are available on the system. sh, or any shell, can be used as just another command.
I have a script that looks like this
#!/bin/bash
function something() {
echo "hello world!!"
}
something | tee logfile
I have set the execute permission on this file and when I try running the file like this
$./script.sh
it runs perfectly fine, but when I run it on the command line like this
$sh script.sh
It throws up an error. Why does this happen and what are the ways in which I can fix this.
Running it as ./script.sh will make the kernel read the first line (the shebang), and then invoke bash to interpret the script. Running it as sh script.sh uses whatever shell your system defaults sh to (on Ubuntu this is Dash, which is sh-compatible, but doesn't support some of the extra features of Bash).
You can fix it by invoking it as bash script.sh, or if it's your machine you can change /bin/sh to be bash and not whatever it is currently (usually just by symlinking it - rm /bin/sh && ln -s /bin/bash /bin/sh). Or you can just use ./script.sh instead if that's already working ;)
If your shell is indeed dash and you want to modify the script to be compatible, https://wiki.ubuntu.com/DashAsBinSh has a helpful guide to the differences. In your sample it looks like you'd just have to remove the function keyword.
if your script is at your present working directory and you issue ./script.sh, the kernel will read the shebang (first line) and execute the shell interpreter that is defined. you can also call your script.sh by specifying the path of the interpreter eg
/bin/bash myscript.sh
/bin/sh myscript.sh
/bin/ksh myscript.sh etc
By the way, you can also put your shebang like this (if you don't want to specify full path)
#!/usr/bin/env sh
sh script.sh forces the script to be executed within the sh - shell.
while simply starting it from command line uses the shell-environemnt you're in.
Please post the error message for further answers.
Random though on what the error may be:
path specified in first line /bin/bash is wrong -- maybe bash is not installed?