I came across the following in trying to implement a nested shell
inside a ksh debugger, but I think the issue is more general.
I'll soon release an update to kshdb. In that will be the ability to
go into a nested shell to enter shell commands rather than issue
them escaped some way inside the debugger. Before going into the shell
though, I take a snapshot of variables and functions and save that to
a file;
the shell profile becomes this file largely setting variable and
functions.  To indicate the special profile, environment variable ENV
is used and
ksh option -E is added.

This works, but I note that in setting using -E also means
/etc/profile is run and setting ENV means that prior values of ENV or
HOME/.kshrc are superseded. (I should probably test for those values
and chain them inside my generated profile).

But more generally it would be nice though if there were either a ksh
command flag which could be given several times or environment
variable
that allowed a list of profiles to be sourced before the main script is run.

I think of having a series of little shell scripts that  are analogous
to loading modules in Perl (-m), Python (-m) or Ruby (-r).
In  those languages allow the corresponding module option to be given
many times so that several modules can be loaded (in
the order given) before running the main script or command string.

Some ways this is used in those languages or some specific ksh uses:
  profiling code
  benchmarking timings
  installing signal default signal handlers
  setting up some sort of special logging
  testing code coverage
  setting up "set -x" tracing with an enhanced PS4 setting.

Individually, one can write each of the "modules" as a standalone
program and that may be desirable in of itself.
But in doing so, one loses $0, the call nesting is different, and it
becomes hard to combine modules such as the logging along with the
default signal handler module.

Comments?

_______________________________________________
ast-developers mailing list
[email protected]
https://mailman.research.att.com/mailman/listinfo/ast-developers

Reply via email to