Bash equivalent of cmd /k switch

[Ben]

On Windows, cmd.exe has the /k switch, which lets you execute a
command given by a command-line argument, and then the shell remains
open after finishing the execution of the command. I know bash has -c
which lets you execute a command given by a command-line argument, but
then the shell closes after finishing the command (this is analogous
to the cmd.exe /c switch). My question is, is there a bash equivalent
of the cmd.exe /k switch that can be used to execute a command and
then remain open?

[pk]

Post by Ben
On Windows, cmd.exe has the /k switch, which lets you execute a
command given by a command-line argument, and then the shell remains
open after finishing the execution of the command. I know bash has -c
which lets you execute a command given by a command-line argument, but
then the shell closes after finishing the command (this is analogous
to the cmd.exe /c switch). My question is, is there a bash equivalent
of the cmd.exe /k switch that can be used to execute a command and
then remain open?

Maybe I don't understand your request...

$ echo $SHELL
/bin/bash
$ bash -c 'ls'
file1 file2
$ # shell is still open here.

[Kenneth Brody]

Post by pk

Post by Ben
On Windows, cmd.exe has the /k switch, which lets you execute a
command given by a command-line argument, and then the shell remains
open after finishing the execution of the command. I know bash has -c
which lets you execute a command given by a command-line argument, but
then the shell closes after finishing the command (this is analogous
to the cmd.exe /c switch). My question is, is there a bash equivalent
of the cmd.exe /k switch that can be used to execute a command and
then remain open?

Maybe I don't understand your request...
$ echo $SHELL
/bin/bash
$ bash -c 'ls'
file1 file2
$ # shell is still open here.

Yes, but you're back to your original shell, not the subshell.

This demonstrates his question:

[elided]$ echo $$
26816
[elided]$ bash -c 'echo my PID is $$'
my PID is 28050
[elided]$ echo $$
26816

He wants the subshell to remain once the command passed to it is executed,
which is what Windows' "cmd /k" would do.

[Marcel Bruinsma]

Post by Kenneth Brody
He wants the subshell to remain once the command passed to it is
executed, which is what Windows' "cmd /k" would do.

He could put the command(s) in a file, then run bash with
the --rcfile option.

[David W. Hodgins]

Post by Ben
to the cmd.exe /c switch). My question is, is there a bash equivalent
of the cmd.exe /k switch that can be used to execute a command and
then remain open?

I think you're looking at the wrong command. Bash is a shell, not a
terminal emulator. Depending on terminal emulator you're using, try ...

konsole -noclose -e ls
xterm -hold -e ls

Regards, Dave Hodgins

[Huibert Bol]

My question is, is there a bash equivalent of the cmd.exe /k switch
that can be used to execute a command and then remain open?

Not exactly, but you can get almost the same effect using:

$ bash -c 'your-command; exec bash'

[Janis Papanagnou]

Post by Ben
On Windows, cmd.exe has the /k switch, which lets you execute a
command given by a command-line argument, and then the shell remains
open after finishing the execution of the command. I know bash has -c
which lets you execute a command given by a command-line argument, but
then the shell closes after finishing the command (this is analogous
to the cmd.exe /c switch). My question is, is there a bash equivalent
of the cmd.exe /k switch that can be used to execute a command and
then remain open?

bash # opens a new shell instance
some_command # exectutes some_command in the new shell instance
# you won't leave the new shell instance
# here you're still in the second shell instance
# do whatever you like
exit # now you're leaving the second shell instance
# here you're back in the first shell instance


There's really no need for those DOS "features".

Janis

[Nate Eldredge]

Post by Ben
On Windows, cmd.exe has the /k switch, which lets you execute a
command given by a command-line argument, and then the shell remains
open after finishing the execution of the command. I know bash has -c
which lets you execute a command given by a command-line argument, but
then the shell closes after finishing the command (this is analogous
to the cmd.exe /c switch). My question is, is there a bash equivalent
of the cmd.exe /k switch that can be used to execute a command and
then remain open?

You could write your command to a file, and use --rcfile to point to
it. But I'm having a hard time understanding why you want to do this;
most of the things I can imagine to do with this have better ways of
doing them. What's your goal here?

[David Schwartz]

Post by Nate Eldredge
You could write your command to a file, and use --rcfile to point to
it.  But I'm having a hard time understanding why you want to do this;
most of the things I can imagine to do with this have better ways of
doing them.  What's your goal here?

My guess would be that he wants to set up the shell in a special way.
Maybe he wants to set environment variables, the prompt, the current
working directory, and so on. This way, he can drop the user into a
shell especially configured for some application.

DS

[Janis Papanagnou]

Post by David Schwartz

Post by Nate Eldredge
You could write your command to a file, and use --rcfile to point to
it. But I'm having a hard time understanding why you want to do this;
most of the things I can imagine to do with this have better ways of
doing them. What's your goal here?

My guess would be that he wants to set up the shell in a special way.
Maybe he wants to set environment variables, the prompt, the current
working directory, and so on. This way, he can drop the user into a
shell especially configured for some application.

So probably one of...

bash # start instance
cmd1
cmd2
cmd3
exit # leave instance

or...

bash <<< "cmd1; cmd2; cmd3"

or...

bash << EOT
cmd1
cmd2
cmd3
EOT


Janis

Post by David Schwartz
DS

[Scott Lurndal]

Post by David Schwartz

Post by Nate Eldredge
You could write your command to a file, and use --rcfile to point to
it. =A0But I'm having a hard time understanding why you want to do this;
most of the things I can imagine to do with this have better ways of
doing them. =A0What's your goal here?

My guess would be that he wants to set up the shell in a special way.
Maybe he wants to set environment variables, the prompt, the current
working directory, and so on. This way, he can drop the user into a
shell especially configured for some application.
DS

Why not use .profile/.login/.kshrc/.bashrc as appropriate for the shell
being used?

scott

[David Schwartz]

Post by Scott Lurndal
Why not use .profile/.login/.kshrc/.bashrc as appropriate for the shell
being used?

I would consider it rude for a script or program that creates a
specialized shell to mess with those files.

DS

[Gordon Burditt]

Post by David Schwartz

Post by Scott Lurndal
Why not use .profile/.login/.kshrc/.bashrc as appropriate for the shell
being used?

I would consider it rude for a script or program that creates a
specialized shell to mess with those files.

I have seen some scripts that do this sort of thing by setting $HOME
to a newly-created temporary directory and it creates its own new
version of those startup files in that directory, then deletes them
when it's through. I don't consider that rude. Confusing, usually.

One place where it can be used to advantage is an emergency repair
disk, where you're booted off of floppy or CD, the normal root disk
is mounted somewhere else, and $PATH needs to be something decidedly
non-standard in order to do anything. Something is broken, and
you're trying to fix it by, say, copying a critical shared library
off of the distribution CD to a filesystem being repaired, or restoring
a backup copy of the password file.

Another possible use for this involves environments inside jails or
chroot'ed setups. You want a command shell *inside* the environment
so you can test your script or fix something.

[Scott Lurndal]

Post by David Schwartz

Post by Scott Lurndal
Why not use .profile/.login/.kshrc/.bashrc as appropriate for the shell
being used?

I would consider it rude for a script or program that creates a
specialized shell to mess with those files.
DS

I was thinking more along the lines of

KSHRC=.prerunfile ksh or
BASHRC=.prefunfile bash

scott

[Nate Eldredge]

Post by David Schwartz

Post by Nate Eldredge
You could write your command to a file, and use --rcfile to point to
it.  But I'm having a hard time understanding why you want to do this;
most of the things I can imagine to do with this have better ways of
doing them.  What's your goal here?

My guess would be that he wants to set up the shell in a special way.
Maybe he wants to set environment variables, the prompt, the current
working directory, and so on. This way, he can drop the user into a
shell especially configured for some application.

In which case, one could just set the environment variables (including
PSn), change the directory, etc, before invoking the shell. One could
do this manually with chdir, putenv, etc, after fork and before exec, or
just do something lazier like

system("cd /some/dir; PS1=\"COMMAND>\"; MYVAR=MYVALUE; export PS1 MYVAR; bash");

[Lew Pitcher]

Post by Ben
My question is, is there a bash equivalent
of the cmd.exe /k switch that can be used to execute a command and
then remain open?

No. Probably because bash isn't the right tool for /that/ job.

Try
xterm -e "ps ; exec bash"
to get the equivalent of the CMD.EXE /k option.

Note that CMD.EXE opens a GUI text window, executes commands in it, and
closes it again; there is no direct equivalent to this in Unix, as bash
(and all other shell processors) are not GUI, and do not open windows for
themselves. OTOH, xterm /is/ GUI and /does/ open a text window in which you
can run commands, including the command to run a shell interpreter.

[Jonathan de Boyne Pollard]

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<blockquote cite="mid:7a8f6$4a25987f$4c0aa020$***@TEKSAVVY.COM-Free"
type="cite">
<blockquote type="cite">
<p wrap="">My question is, is there a bash equivalent of the <code>cmd.exe
/k</code> switch that can be used to execute a command and then remain
open?<br>
</p>
</blockquote>
<p wrap="">No. Probably because bash isn't the right tool for <em>that</em>
job.<br>
</p>
</blockquote>
<p>[...]</p>
<blockquote cite="mid:7a8f6$4a25987f$4c0aa020$***@TEKSAVVY.COM-Free"
type="cite">
<p wrap="">Note that <code>CMD.EXE</code> opens a GUI text window,
executes commands in it, and closes it again; there is no direct
equivalent to this in Unix, as <code>bash</code> (and all other shell
processors) are not GUI, and do not open windows for themselves.<br>
</p>
</blockquote>
<p>Neither does <code>CMD</code>, which is in fact precisely like <code>bash</code>
in this regard in that it has no notion of a graphical user interface. 
You are incorrect.</p>
<p>What the <code>/k</code> option does is force <code>CMD</code> to
enter
interactive mode after it has finished processing whatever command was
on its command-line.  (With the <code>/c</code> option it does not
enter interactive mode.  With neither <code>/c</code> nor <code>/k</code>
the default is to enter interactive mode.)  The creation and
destruction of the Win32 console is not done by <code>CMD</code>.  It
just uses whatever console it inherits.  And it only even uses at all
it if it enters interactive mode.<br>
</p>
<p>Yes, there's no <code>bash</code> equivalent to <code>/k</code>.
Interestingly, and not yet noted in this thread, the POSIX <code>sh</code>
<a href="http://opengroup.org./onlinepubs/000095399/utilities/sh.html">is
defined</a> as accepting both <code>-c</code> and <code>-i</code>
together, meaning that with a POSIX-conformant shell, one could,
according to the text of the standard at least, use <code>sh -i -c <i>command</i></code>
to achieve the same as <code>/k</code>.  The <code>bash</code>
documentation indicates these two to be mutually exclusive, however. 
This is a defect in the standard, in my view.<br>
</p>
</body>
</html>

[Sidney Lambe]

Post by Jonathan de Boyne Pollard
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

If you want your article read here, post using plain text.

[delete]

Killfiled another idiot.


Sid

comp.unix.shell

[Ben Finney]

(Ben, any chance you could set your full name in the From field of your
messages? It would make discussions like this less confusing.)

Post by Ben
On Windows, cmd.exe has the /k switch, which lets you execute a
command given by a command-line argument, and then the shell remains
open after finishing the execution of the command.

Note that ‘cmd.exe’ is a program that gives a windowed terminal
emulator, and it is that terminal emulator that remains after the
commands within it have ended.

Post by Ben
I know bash has -c which lets you execute a command given by a
command-line argument, but then the shell closes after finishing the
command

The ‘bash’ program, on the other hand, has nothing to do with providing
a terminal emulator; it runs within a terminal provided by something
else.

Post by Ben
(this is analogous to the cmd.exe /c switch).

Analogous, but not helpful in this case. The two jobs of “terminal
emulator” and “command shell” are separate on Unix, but conflated on
Windows.

Post by Ben
My question is, is there a bash equivalent of the cmd.exe /k switch
that can be used to execute a command and then remain open?

Not in bash (or any shell), no. What you want is to investigate how your
terminal emulator can do this (e.g. by reading the man page for
‘xterm(1)’, ‘gnome-terminal(1)’, ‘rxvt(1)’, or whichever terminal
emulator you choose).

[Kenneth Brody]

Post by Ben Finney

Post by Ben
On Windows, cmd.exe has the /k switch, which lets you execute a
command given by a command-line argument, and then the shell remains
open after finishing the execution of the command.

Note that ‘cmd.exe’ is a program that gives a windowed terminal
emulator, and it is that terminal emulator that remains after the
commands within it have ended.

[...]

Post by Ben Finney
The ‘bash’ program, on the other hand, has nothing to do with providing
a terminal emulator; it runs within a terminal provided by something
else.

Incorrect. cmd.exe is a command shell, which runs in a console window
supplied by Windows. It does not supply a "terminal emulator" any more than
bash does.

[...]

[pk]

Post by Kenneth Brody

Post by Ben Finney

Post by Ben
On Windows, cmd.exe has the /k switch, which lets you execute a
command given by a command-line argument, and then the shell remains
open after finishing the execution of the command.

Note that ‘cmd.exe’ is a program that gives a windowed terminal
emulator, and it is that terminal emulator that remains after the
commands within it have ended.

[...]

Post by Ben Finney
The ‘bash’ program, on the other hand, has nothing to do with providing
a terminal emulator; it runs within a terminal provided by something
else.

Incorrect. cmd.exe is a command shell, which runs in a console window
supplied by Windows. It does not supply a "terminal emulator" any more
than bash does.

Under Linux, say kde, if you choose "run command..." from the K menu and
type "/bin/bash", nothing happens unless you tick "run in terminal window",
which clearly shows that the two functions are distinct.

In windows, AFAICT, if you choose start -> run, and type "cmd.exe", you are
dropped straight into a window with cmd.exe running inside. I don't know
whether that's done by windows or cmd.exe itself, but sure that's not the
same of what happens in linux.

[Kenny McCormack]

In article <h0m4m1$9ji$***@aioe.org>, pk <***@pk.invalid> wrote in
response to someone else (hereinafter, SE):
...

Post by pk

Post by Kenneth Brody
Incorrect. cmd.exe is a command shell, which runs in a console window
supplied by Windows. It does not supply a "terminal emulator" any more
than bash does.

Under Linux, say kde, if you choose "run command..." from the K menu and
type "/bin/bash", nothing happens unless you tick "run in terminal window",
which clearly shows that the two functions are distinct.
In windows, AFAICT, if you choose start -> run, and type "cmd.exe", you are
dropped straight into a window with cmd.exe running inside. I don't know
whether that's done by windows or cmd.exe itself, but sure that's not the
same of what happens in linux.

You're both right, of course.

SE is right on the pedantic particulars (see below), but you are right
about your observed behavior. Nobody is denying that what your observe
is what really happens.

The pedantic (and off-topic, since this newsgroup has the word Unix in
its name and these are Windows-specific points) particulars: SE is
correct that CMD.EXE is no more a terminal emulator than bash is.
CMD.EXE runs inside a process's console just like any other console mode
app would. The key difference is that under Windows (current, NT-based,
strains of Windows), if a console mode app is launched and there is no
console to run it in, one is automatically allocated for it. Interested
readers can look on MSDN for the relevant details and specific APIs used.

This is, to me, desirable behavior, and something that, if Unix were to
be redesigned today, would be found also in Unix. To have, as you
describe, "nothing happen"ing when you run a program (e.g., bash) is,
obviously, undesirable.

[pk]

Post by Kenny McCormack
The pedantic (and off-topic, since this newsgroup has the word Unix in
its name and these are Windows-specific points) particulars: SE is
correct that CMD.EXE is no more a terminal emulator than bash is.
CMD.EXE runs inside a process's console just like any other console mode
app would. The key difference is that under Windows (current, NT-based,
strains of Windows), if a console mode app is launched and there is no
console to run it in, one is automatically allocated for it. Interested
readers can look on MSDN for the relevant details and specific APIs used.

Thanks, I was ignorant (and still am, but maybe a bit less) about this
specific aspect of windows. Now I can see that the we were both correct,
only from different points of view as you said.

[Ben Bacarisse]

***@shell.xmission.com (Kenny McCormack) writes:
<snip>

Post by Kenny McCormack
The pedantic (and off-topic, since this newsgroup has the word Unix in
its name and these are Windows-specific points) particulars: SE is
correct that CMD.EXE is no more a terminal emulator than bash is.
CMD.EXE runs inside a process's console just like any other console mode
app would. The key difference is that under Windows (current, NT-based,
strains of Windows), if a console mode app is launched and there is no
console to run it in, one is automatically allocated for it. Interested
readers can look on MSDN for the relevant details and specific APIs used.
This is, to me, desirable behavior, and something that, if Unix were to
be redesigned today, would be found also in Unix. To have, as you
describe, "nothing happen"ing when you run a program (e.g., bash) is,
obviously, undesirable.

I disagree. I run bash scripts with no terminal emulation all the
time. I don't want the two functions to be linked.

[pk]

Post by Ben Bacarisse
<snip>

Post by Kenny McCormack
The pedantic (and off-topic, since this newsgroup has the word Unix in
its name and these are Windows-specific points) particulars: SE is
correct that CMD.EXE is no more a terminal emulator than bash is.
CMD.EXE runs inside a process's console just like any other console mode
app would. The key difference is that under Windows (current, NT-based,
strains of Windows), if a console mode app is launched and there is no
console to run it in, one is automatically allocated for it. Interested
readers can look on MSDN for the relevant details and specific APIs used.
This is, to me, desirable behavior, and something that, if Unix were to
be redesigned today, would be found also in Unix. To have, as you
describe, "nothing happen"ing when you run a program (e.g., bash) is,
obviously, undesirable.

I disagree. I run bash scripts with no terminal emulation all the
time. I don't want the two functions to be linked.

I think what Kenny was referring to is programs that request or need the
allocation of new terminals (pty etc.), which of course is not the case
with cron jobs or background or non-interactive scripts (if that's what
you're referring to).

[Giorgos Keramidas]

Post by Ben
On Windows, cmd.exe has the /k switch, which lets you execute a
command given by a command-line argument, and then the shell remains
open after finishing the execution of the command. I know bash has -c
which lets you execute a command given by a command-line argument, but
then the shell closes after finishing the command (this is analogous
to the cmd.exe /c switch). My question is, is there a bash equivalent
of the cmd.exe /k switch that can be used to execute a command and
then remain open?

A child process inherits the environment of its parent, so you can get a
very similar effect by forking $SHELL at the end of a -c command:

***@kobe:/home/keramida$ env FOO=1 \
bash -c 'echo $FOO ; exec $SHELL'
1
***@kobe:/home/keramida$ echo FOO is $FOO
FOO is 1
***@kobe:/home/keramida$ exit
exit