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.
Related
I want to do the following thing: I want to replace the systemd program on my CentOS 7 installation, with a script, that will eventually start a shell where the user can input commands as root on the system console.
For this, I used the init=/sbin/myInit parameter. In this script I do some initialization, and in the end I call bash to enable the user to input commands. The interactive bash always appears on the screen.
Unfortunately, there is a problem with the input, that I haven't been able to solve: the input doesn't work correctly. When I press enter, only the second enter works, but no new line is performed on the screen. And when I type some characters, not all the characters are read. It seems like the console is in some Unicode mode (stty -a shows iutf8 parameter), and bash cannot correctly read the input. The output is fine, all the echo commands in my script are correctly printed on the screen (I only print ASCII characters).
I've tried all sorts of combinations, with different LC_ALL settings (LC_ALL=C, LC_ALL=C.utf-8, no LC_ALL or LANG variables initialization), redirect stdin/stdout/stderr to /dev/console, /dev/tty0 or /dev/tty1, the TERM variable is initialized to linux value, but nothing works. I tried unicode_start and unicode_stop commands, but unicode_stop doesn't work, and I get the error message "stty: standard input: unable to perform all requested operations". If I run showkey command, and I press the enter key, the correct keycode 28 is detected, same with normal boot.
Even stranger than this is the fact that if I'm using the init=/bin/bash kernel parameter, the input works fine, and if I manually run my script, it also works fine. If I copy the bash executable to something like /bin/mys, and I use init=/bin/mys, than same input problem occurs. It seems like the initrd image treats /bin/bash differently. Maybe it performs some initialization or something, that enables the bash to read correctly from the terminal. Why do we have this difference between init=/bin/bash and init=/bin/mys? It's the same executable in the end.
What am I doing wrong ?
As a general question about the init program, can somebody explain me what the init program should do to work correctly ? Any particular signals it has to respond to, any console initialization to be performed ?
I'm trying to solve this for days, and I cannot find any solution. On the web I couldn't find any article about this. So any suggestion would be greatly appreciated. Thank you.
I managed to pull a solution out for this one.
Turns out, at boot, the console is not initialized. I looked at the differences between the output of stty -a between the normal boot and the script boot (init=/sbin/myInit), and there are some differences between them: the console on normal boot had the following flags active on it: brkint ignpar ixon imaxbell isig icanon iexten echo, while when on script boot, those flags where cleared (stty reports them with - ). I'm not sure what they mean, except the echo flag, which I quickly noticed, because on each key press, no character ware printed on the screen.
So I decided to set those flags on my init script for /dev/console. After digging the stty manual page, I found the sane option, that sets the most important flags for normal console usage. So I added the line stty -F /dev/console sane in my init script.
But, there is a small problem. It seems that some console options cannot be changed by the stty command if the console is already opened by a process. So the first thing I did in my script is to redirect the stdin/stdout/stderr to /dev/null, via the line 0/dev/null, and then add the stty sane line, then redirect back the stdin/stdout/stderr to /dev/console.
I also noticed a process called plymouth, probably started by the CentOS initrd, so before the root was mounted and init script executed. I'm not sure if that process opened the system console, but I decided to eliminate it, by reconstructing a personalized initrd, by omitting the plymouth module from dracut (option -o plymouth).
After doing this, the script worked fine, and the bash process started by the script could read correctly the console.
Hope this helps somebody someday. Cheers
When beginning to work, I have to run several commands:
source work/tools
cd work/tool
source tool
setup_tool
Off course, doing this a few times a day is really annonying, so I tried to make a bash script tool where I put these commands and put it in /user/bin to run it with command
tool
However, there is a problem. When i run the script and then try to work by typing some of the tool-based commands, it does not work.
I figured out, that it is fine, since if I make a script and then run it, the script seems to run in the same terminal window, but what it really does is, that it behaves as if it created a "hidden window" for its execution and after termination of the script, the "hidden window" terminates too. So I am asking - is there a way to automatize the source command?
I have tried using xterm -hold -e command, but it runs the programmed script in the new window. Obviously, I don't want that. How can I achieve running it in the current window?
Don't put files like that in /usr/bin. As a general rule you don't want to mess with the distribution owned locations like that. You can use /usr/local/bin if you need a system-wide location or you can create a directory in your home directory to hold things like this that are for your own usage (and add that to the $PATH).
What you've noticed is that when run as a script on its own (tool, /path/to/tool, etc.) that the script runs in its own shell session (nothing to do with terminal windows as-such) and you don't want that (as the changes the script makes don't persist to your current shell session).
What you want to do instead is "source"/run the script in your current session. Which you are already doing with that set of commands you listed (source work/tools is doing exactly that).
So instead of running tool or /path/to/tool instead use source /path/to/tool or . /path/to/tool.
As fedorqui correctly points out you don't even need a script for this anywhere as you can just make a shell function for this instead (in your normal shell startup files .bashrc, etc.) and then just run that function when you need to so that setup.
Be careful to use full paths for things when you do this though since you, presumably, want this to work no matter what directory you happen to be in when you run it.
It doesn't create a new hidden window, nor does it create a terminal. What happens is that if you're running a script, normally it runs on a new shell process. The script you're running is supposed to modify the shell environment, but if you're running the script in a new shell process, that shell process's environment is the one that gets modified, instead of your shell environment.
Scripts that needs to modify the current shell environments usually must be run with the source command. What you need to do is to run the script in the current shell. So you should do source /path/to/tool.
If you want to be able to source the script with just tool, put this in your alias file/shell startup (check your distro doc where the file is, but it's usually either .bash_aliases or .bashrc):
alias tool="source /path/to/tool"
I was trying to permanently set environmental variables for a linux VM, and I edited the .bashrc file and added two variables there. To see these variables I used the
bash
echo $VARIABLE
to make sure that I set the variables correctly. Now I can't seem to exit the bash though. I don't know if editing these variables has messed up the system now or what. I used VI to edit the file originally, but now I can't undo the changes with VI or anything because I'm getting an error that -bash: vi: command not found.
So my question is, how do I exit bash mode?
Thanks
So the problem as was found was that I edited the PATH variable which then messed around with the entire shell.
In order to reset this I used the . /etc/skel/.bashrc command.
Thanks guys
When I run gvim from MSYS, things go wrong during initialization. Namely, gvim can't find the initialization files that are in 'C:\Documents and Settings\username\vimfiles.
[Specifically, gvim reports the error E117: Unknown function: pathogen#infect during initialization, so it never found autoload\pathogen.vim. Doing :scriptnames also confirms that none of the setup files from vimfiles\ are run.]
I think I've debugged why it goes wrong. When you start MSYS, the MSYS shell inherits the windows enviroment variables, but changes some of them to it's custom values. C:\Documents and Settings\username is the value of $HOME in Windows, but MSYS sets it to something like C:/msys/user name. And of course, Vim uses $HOME to find the right initialization files.
I also notice set shell? has changed to something like shell=C:/msys/bin/sh instead of shell=C:\WINDOWS\system32\cmd.exe, but I hope this isn't important for fixing the initialization problem.
I need to run gvim with the normal windows environment variables. At least I need to be able to manually override a few important ones like $HOME to something I specify (i.e., I'm not concerned about my windows $HOME changing, so it's fine to use a static value).
I tried to reset $HOME manually in my vimrc, but by then it is too late.
Is there some trick to specifying $HOME early on during initialization, or as an extra command line parameter?
Alternatively, is there some trick with running commands from msys differently? I know almost nothing about how the shell C:/msys/bin/sh works, but I could conceive of some extra arguments that changes the visibile environment for the command (e.g. gvim.exe) you are typing.
---Edit---
Reposting the solution that worked (it achieves the later idea):
Instead of running gvim.exe, run the command HOME="C:\Documents and Settings\username" gvim.exe
In bash and other UNIX shells, you can do:
$ HOME='/path/to/dir' gvim
to temporarily set $HOME to a different value.
I admit I'm not familiar at all with the Windows command line, but it might be worth a try.
I believe you can define $HOME just like any other environment variable.
Try adding this to the start of your .vimrc.
let $HOME="C:\Documents and Settings\username"
I had a similar issue when running Cygwin (which is similar to MSYS).
The easiest solution for me was to simply set the HOME environment variable to an empty string. Otherwise, the Cygwin HOME value would be appended to the Windows USERPROFILE in GVim and it would fail to start correctly. Not explicitly setting the full path of the HOME means that I can use the same start-up files on different systems where the USERNAME may not be the same.
Likewise, the SHELL environment variable should not be inherited from Cygwin Bash. This results in errors when running shell or external programs via !. Again, I set this to be an empty variable since Vim is smart enough to figure out what it should be.
In my .bashrc, I set the following alias for running Windows gvim which starts GVim with the HOME and SHELL variables set to an empty string – just for that command.
gvim="/cygdrive/c/Program Files (x86)/Vim/vim74/gvim"
if [ -x "$gvim" ]; then
alias gvim="HOME= SHELL= \"$gvim\""
fi
unset gvim
I achieved this by making a windows symbol link (Win 7 or higher).
Via a symbol link, you can even make vim and gvim to use the same configuration and plugin.
I'm having some problems working with my development environment. Specifically, after I invoke the screen utility from within Cygwin I lose the ability to do tab completion. Before I invoke screen however tab completion works just fine.
I messed around with setting different values for the TERM env variable (VT100, xterm etc) but without success. It must be something trivial but I have no idea anymore. Does StackOverflow have any suggestions for me?
when you issue 'screen' from inside cygwin it might put you in another shell like /bin/sh instead of /bin/bash (and bash is where you're getting the tab completion from).
To fix the problem you could edit your .screenrc file (found in your home directory) and add in this line:
shell bash
Then try running screen again and you should see tab completion work within this new window.
The problem is that bash needs to be run as a login shell in order to have tab completion in the default cygwin setup. If you run bash in a cygwin bash you won’t have tab completion either. To set screen to run bash in login mode, add this line to your ~/.screenrc file:
shell -bash
I had a similar problem with git autocompletion not working when using screen on a linux machine, but wasn't due to a different shell. I fixed it using this question: Git autocomplete in screen on mac os and doing the following:
Get the git autocompletion script
curl https://raw.github.com/git/git/master/contrib/completion/git-completion.bash -OL
why would you want that hanging around?
mv git-completion.bash .git-completion.bash
add this line to your ./bashrc
source ~/.git-completion.bash
Then in your terminal
source ~/.bashrc
That worked for me.
(I imagine after three years you've probably solved your problem, but I hope this helps someone else)