I want to use fish with Cool Retro Terminal but the prompt I use normally has unicode characters, which the fonts in retro terminal don't support. I have my fish_prompt function check if $simple_prompt is 1 or not and I know that it works, but I need a way to set the variable, only for that terminal instance, with the startup command option in retro terminal.
The closest I have so far is fish -c "set -gx simple_prompt 1; fish", but that exports the variable to all the shell instances on the system and makes the prompts simple for all of those too. fish -c "set -g simple_prompt 1; fish" doesn't work.
It is expected that set -g simple_prompt 1 isn't visible to the next fish instance you launch. Global variables are only visible to the current shell instance. If the terminal you are using sets some environment vars that would allow you to determine that fish is running within that specific terminal I would go use that info. For example, iTerm2 on macOS exports ITERM_PROFILE and four other env vars unique to it. If Cool Retro Terminal doesn't do that perhaps there is some other way detect that terminal type. It may be as simple as checking the TERM variable.
If the aforementioned solutions aren't an option then the only solution is an environment variable like in your first solution. Because you say it exports that variable to all fish instances I suspect you did not accurately describe what you are doing. Because if you set that command as the command that Cool Retro Terminal should use to launch your shell it would only affect fish instances running in that terminal. Which is what you want.
Related
I install the cargo building environment.
I use cargo install exa to install exa (an alternatives of command ls).
Executable file is put in $HOME/.cargo/bin.
I use fish shell set -gx PATH $PATH $HOME/.cargo/bin, and then I can use command exa on current session.
But when I open a new session, I cannot execute exa unless set -gx ... again.
I look in the options gx:
--global -g (Make variable scope global)
--export -x (Export variable to subprocess)
Does not global mean every session? Could someone help me pls?
Doesnot global means every session?
It doesn't. It's "global" as opposed to "local". From the fish documentation:
Global variables are specific to the current fish session, and will never be erased unless explicitly requested by using set -e.
In general, what you want is to just put the set -gx into ~/.config/fish/config.fish. That's fish's configuration file.
Fish also has "universal" variables, which are stored persistently, but they interact awkwardly with exporting so I wouldn't recommend it.
For $PATH specifically, fish offers the fish_user_paths variable that it adds automatically, so you can run
set -U fish_user_paths $fish_user_paths $HOME/.cargo/bin
once, interactively, and fish will take care of it. This is a universal variable, but fish takes care to add it to $PATH when necessary (for each component it checks if it's already there and such). Do not put this into config.fish, or it will add one $HOME/.cargo/bin every time you start a fish, and so it would balloon the variable.
To recap:
For global variables, put the set statement into config.fish
For universal variables, execute it manually
For $PATH, use $fish_user_paths for your customizations
While installing a new RHEL on KVM host I am displaying a text file using more command. Problem is more is behaving like cat in virt-manager i.e. not displaying page-by-page and directly scrolling to the end of the page. I tried using less instead of more but it is displaying the same behavior.
Can anyone suggest what could be the reason for this?
Edit Based on comments I tried changing TERM to xterm during first boot. But that didn't have any effect. I tried this command export TERM=xterm
I got the env variables printed. I am pasting it hoping this might be a clue.
Edit I couldn't get it working. I noticed that before the script is executed, some other script is running and this might be setting some environment variable because of which more isn't working. I am now calling more command before this script start executing. And now it is working.
I suspect your environment is not correct. Specifically your $TERM environment variable may not be set. See here for the more manual entry.
The more command respects the following environment variables, if
they exist:
MORE This variable may be set with favored options to more.
SHELL Current shell in use (normally set by the shell at login
time).
TERM The terminal type used by more to get the terminal
characteristics necessary to manipulate the screen.
VISUAL The editor the user prefers. Invoked when command key v is
pressed.
EDITOR The editor of choice when VISUAL is not specified.
After help from a senior dev, I found out what was happening behind the scenes.
Suppose A.sh is executing more command like below:
more pathtofile
A.sh is being called by some other script like below:
pathtoA.sh | tee
Because of this tee command, more command in child script was not behaving as it should have been.
I want to open a new xterm with a custom prompt string.
Since prompt is set using the prompt variable, I thought I could just run:
xterm -e "set prompt = $prompt_string_of_my_choosing" #The organization I work for uses tcsh
The problem is, I want the xterm to stay interactive.
I tried tcsh -c as a command for -e, I tried sourcing another script that would set the prompt to the way I want it . The results I'm getting are either an interactive shell with the default prompt, or an xterm that just closes (or stays open with -hold but not interactive).
I was however able to bypass the problem by adding the following to ~/.cshrc:
if ($?calling_prompt) then
set prompt = "$calling_prompt"
endif
And of course I preset the $calling_prompt variable in advance.
This works, but requires me to edit ~/.cshrc, so it's not a global solution.
Any ideas?
Maybe you can set variable being a flag for your new term and than use this approach:
http://www.owsiak.org/?p=2582
This way, you can alway set whatever you like in prompt - e.g. based on type of term you have started.
In my shell I did: export BLA=foo and then I do echo $BLA and I see foo as expected. I then load up emacs and do M-! for a shell command and do echo $BLA and it's set to something else, bar. So then I run M-x setenv and give it BLA and foo at the prompts but when i do the echo i still see bar. Why would that be and how can I change it? I am trying to do this for some environment variables under which I want to run M-x compile
setenv will modify the environment for the processes emacs launch after you set the value. Running child processes will not be affected.
Thus, doing a (setenv "FOO" "bar") and then M-x shell (provides you have not a running shell yet) will produce a shell with environment variable "FOO" set to "bar".
Your shell in which you've started the Emacs hands over a copy of its environment to its child process (the Emacs), that's how the value is transmitted from the shell to the Emacs. Any change the Emacs then performs with its inherited environment will only affect the Emacs process's environment. There is no way the Emacs's environment can influence the environment of the shell.
If you need to hand information back to the shell, you have to use different techniques like temp files, named pipes, sockets, …
If you just want to check the environment of the Emacs itself, use M-x getenv to look at variables, or use M-! echo $BLA. If this also is showing sth else, then you probably have a special BLA which is automatically set to sth after each command, or which isn't writable at all like RANDOM or similar.
Is there a way to launch a gnome-terminal from the command line (i.e., using the /usr/bin/gnome-terminal command) and have the new terminal inherit the environment variables and other set variables of terminal from which the command was run? The scenario is thus:
Open a terminal
Set some variables
Set some environment variables
Launch an executable that needs the variables and the environment variables of the current terminal in a new terminal
Thoughts?
This turned out to be a gnome-terminal issue. When launching the gnome-terminal, specifying the --disable-factory option provides the following directive:
"Do not register with the activation name server, and do not reuse an already running GNOME terminal process" (gnome-terminal man page)
Specifying this option was required in order to inherit the environment of the previous shell.
You need to use export against the variables in the other shell if you want child processes to inherit them.