🚀 go-pugleaf

On Tue, 02 Jun 2009 15:28:17 -0400, Ben <bgold12@gmail.com> wrote:

> 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

-- 
Change nomail.afraid.org to ody.ca to reply by email.
(nomail.afraid.org has been set up specifically for
use in usenet. Feel free to use it yourself.)

Ben wrote:

> 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'

-- 
Huibert
"The Commercial Channel! All commercials all the time.
 An eternity of useless products to rot your skeevy little mind, forever!"
   -- Mike the TV (Reboot)

Ben wrote:
> 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

Ben <bgold12@gmail.com> writes:

> 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?

On June 2, 2009 15:28, in comp.unix.programmer, Ben (bgold12@gmail.com)
wrote:

> 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.

-- 
Lew Pitcher

Master Codewright & JOAT-in-training | Registered Linux User #112576
http://pitcher.digitalfreehold.ca/   | GPG public key available by request
----------      Slackware - Because I know what I'm doing.          ------

On Jun 2, 1:56 pm, Nate Eldredge <n...@vulcan.lan> wrote:

> 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

David Schwartz wrote:
> On Jun 2, 1:56 pm, Nate Eldredge <n...@vulcan.lan> wrote:
> 
> 
>>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

> 
> DS

David Schwartz <davids@webmaster.com> writes:
>On Jun 2, 1:56=A0pm, Nate Eldredge <n...@vulcan.lan> wrote:
>
>> 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 <davids@webmaster.com> writes:

> On Jun 2, 1:56�pm, Nate Eldredge <n...@vulcan.lan> wrote:
>
>> 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");

On Jun 2, 5:25 pm, sc...@slp53.sl.home (Scott Lurndal) wrote:

> 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

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

Ben <bgold12@gmail.com> writes:

> 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.

> 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.

> (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.

> 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).

-- 
 \       “Science shows that belief in God is not only obsolete. It is |
  `\                        also incoherent.” —Victor J. Stenger, 2001 |
_o__)                                                                  |
Ben Finney

>> 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.

David Schwartz <davids@webmaster.com> writes:
>On Jun 2, 5:25=A0pm, sc...@slp53.sl.home (Scott Lurndal) wrote:
>
>> 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

Ben Finney wrote:
> Ben <bgold12@gmail.com> writes:
> 
>> 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.
[...]
 > 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.

[...]

-- 
Kenneth Brody