Perhaps spawn a copy of whatever shell using Expect or IPC::Run and send whatever (filtered? I presume) input from your source to that subprocess.
| [reply] |
Thanks.
yup, it's a command filter since the Export Control..to instead of the common telnet.
They are all not standard perl modules. I need some low level solutions...
| [reply] |
| [reply] |
I don't really know how to do it, but at least I know how it's called, a REPL, read-eval-print-loop.
Perhaps searching for that might reveal some ideas. Perhaps the source of Devel::REPL is inspiring as well. | [reply] |
| [reply]
[d/l]
[select] |
ls(1) runs in a child process, it is an external program. This is the case whether you run it from bash or perl. cd is a shell built-in, and does not create a child process. It alters the current directory, which is then inherited by any child processes. I am not sure what you intend to do - running built-ins in the same shell is fine, just redirect the shell's STDIN using open with a pipe, then print the commands to the pipe handle. Not sure what you will achieve running external programs this way though (to be honest I'm not sure why you want to use a shell at all).
Maybe this is semantics. A subshell is a shell mechanism where a separate environment is created, but a child process is not fork'ed if all the commands are built-ins. Think of it as an evnironment stack - changes are lost when the stack is collapsed at the end of the subshell.
| [reply] |
You could write the commands to a file and execute the file.
print `/bin/bash /tmp/command_file_123 2>&1`;
| [reply]
[d/l] |
Even if user inputs "sh", I hope it can fork a bash that cover the default csh and then user can run their following commands in the bash.
"sh" runs Bash as a Bourne shell look-alike, you do not get full bash. sh is often a symbolic link to bash, but bash checks how it was called and acts accordingly (not uncommon).
Easiest was to override csh is to place "exec bash" in .login. | [reply] |