Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Closed 8 years ago.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Improve this question
Is it possible to change the default interactive shell of a user on a Unix (Solaris) system without any impact on other software that remotely logs in via the same username (eg: via rsh or ssh).
Rationale: my company sells multi-million dollar machines that still have csh as the default shell. Since csh is very user unfriendly (eg: no history browsing via up/down arrow keys), I proposed to change the default shell to tcsh. Tcsh should be backwards compatible with csh, but apparently it still causes problems for some scripts that remotely login to the machine.
Since there's no real business case to upgrade the shell and to fix all existing scripts, I'm looking for a simple solution with little effort.
You probably want distinguish between interactive vs batch shells as opposed to remote vs local ones, right? For the former case, you should examine $- variable in your .profile script.
Thinking more about this, csh is not that great at providing the same information as Bourne shell family. Unless there is indeed a "standard" way for it to detect interactive mode, you have two alternative options:
Replace csh login shell with ksh and (after doing the check above) do exec csh for interactive sessions.
In .login (or whatever that script is called for csh) check the parent process name and if it is login, getty, xdm (or whatever is used for login in your system) then your session is interactive (another alternative is to check the EUID of the parent process).
Just don't change (again) the default shell. Changing it in the first place from sh to csh was a mistake. Doing it again would be another one.
There is no point in introducing compatibility breaks, especially with Solaris which is quite serious about maintaining compatibility.
What you might do (although sometimes regarded as controversial) is to create aliases for the affected user accounts, i.e. entries with a different username, password and shell but with an identical uid, gid and home directory.
That would allow remote scripts to still use the legacy environment while the real users would use the shell of their choice.
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 2 years ago.
Improve this question
Often when working on a project I start by opening a single terminal and executing commands normally, and then find that I need another terminal window so I start a tmux session and split into 2, 3, etc panes. However, I'm working with ros and other tools and often need to execute commands like source devel/setup.bash etc to set up env variables and make certain tools available.
Is there an easy way to automatically convert my current terminal state (including up-arrow history, environment variables, everything sourced, etc to a new tmux session? Something like tmux new-session --from-current-state?
I know I can use a config to automatically run commands on a new tmux startup but I'd rather have it flexibly use the current terminal state so that I can use it for multiple projects etc without having to write a new config file for each environment.
Thanks for the suggestions. I guess I'll go with echo "tmux" >> ~/.bashrc...
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 5 years ago.
Improve this question
I have vim and mintty installed with cygwin.
Have some aliases in bash profile, they work in terminal.
Then I call :!bash from vim, I have the same mintty terminal, but have to source .bash_profile again.
My original intent was to call command :!chrome %
In order to save some overhead, the default shell used by Vim to invoke external commands (i.e. via :! {cmd}) is a non-interactive one; it doesn't read the usual initialization files.
If you want to use shell aliases, you can reconfigure Vim to start an interactive one (adding the i flag):
:set shellcmdflag=-ic
Aliases are typically defined in .bashrc; however, you mention .bash_profile. That one is only read for login shells, so either move the alias definitions, or start an (even slower) login shell by supplying the l flag in addition to i.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 6 years ago.
Improve this question
Like sed, there are shell commands which don't behave in the same way in the same shell.
Behavior of them seems to be different depending on OS (*BSD or GNU/Linux) not on shell though they are shell commands. I wonder at this. Could anyone please explain why shell scripting doesn't behave the same way on multiple platforms?
Different systems evolved their own tools and syntax, to a certain degree. Linux uses the GNU toolchain, which supports a variety of modern options. However, there is one thing that Linux and BSD (and many other Operating Systems) have in common: POSIX.
This is the POSIX specification for sed. You can rely on these working on all *nix platforms. There is usually a way to do whatever you're trying to do in a way that works with all versions of sed.
You'll also find the same inconsistencies between awk and gawk.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Closed 9 years ago.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Improve this question
How can I find a process is owned by which shell?
It is useful as I have a server with multiple logged in users and a few long-running processes, and I want to know which users can I force log-out without stopping their started jobs.
The output of ps is reporting a TTY, but it is not useful as even after disowning a job, its TTY remains the same. So how can I find out if a user disown/nohuped its started processes?
You can't find the “owner shell” in the sense you're describing, because there's no such thing. You can find the parent process, which may be a shell; but you can't know whether the shell disowned the job, because that operation is purely internal to the shell.
What you should really do is instruct your users to start long-running programs inside Screen or Tmux. These are somewhat complex programs, but for basic use, they are very simple.
Start a Screen session by running the command screen.
You can run commands inside that session, and they'll keep running even if you log out.
If you want to log out with a command still running, disconnect from the Screen session by typing Ctrl+A D.
To reconnect to an existing Screen session, run screen -rd.
If you exit the shell inside a Screen session, the session exits.
You could perhaps make a wrapper script around long-running processes that starts screen automatically.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 9 years ago.
Improve this question
I was just curious about the logic of a Unix environment. I'm under the impression that Unix is an operating system, but also a shell. As a subset there are more specific shells such as Bourne, Bash, and Korn shells. And these shells are interpreters and have their own functions to interpret scripts, and also have functions such as ping, pwd, etc? So there are shells within shells? Is everything I said correct?
The Unix operating system is not a shell.
A shell is just a program that makes it easy to interact with your computer by running programs and manipulating data streams.
The 'functions' you mentioned are programs, and not part of the shell.
You can run a shell from another shell if you want. For example, you are in a bash session and you want to switch to csh for something. You run csh and when you're finished, you exit to return to the bash shell.
If you like, you can run another copy of bash inside a bash session. You might do this if you want to modify some environment variables and then undo your changes when you return.
In all these cases, all you did was run a program from a shell and waited for it to terminate. If that program also happened to be a shell, it's nothing special.