Casper.Dik at sun.com wrote:
In general I am requesting the ARC people to burry this issue and let
the project team come up with a solution in peace - which means don't
rip out pfksh93 from this ARC case - there are at least three existing
ways to deal with the problem (see my other email) and
In general I am requesting the ARC people to burry this issue and let
the project team come up with a solution in peace - which means don't
rip out pfksh93 from this ARC case - there are at least three existing
ways to deal with the problem (see my other email) and IMO we have
plenty of time
Casper.Dik at sun.com wrote:
The pf*sh issue is somewhat broader than just the builtins.
In the ideal world the pf*sh would just have a flag bit set and the
kernel would take care of most of the rest. (So a pf*sh would not
involve changing the code in the shell).
So it looks like you are
Darren J Moffat writes:
Now personally I recommend to people when writing scripts that use a
profile never to depend on $PATH and always fully specify the paths.
A bit off-topic, but I disagree with that. For trivial scripts,
littering the code with /foo/bar/baz isn't too horrible, but for
Darren J Moffat Darren.Moffat at Sun.COM wrote:
All of the three that you listed may require changes to the script,
that seems wrong because it is introducing incompatibility between pfksh
and pfksh93 when the longer term goal is that ksh93 become the default.
Now personally I recommend to
Joerg Schilling wrote:
Darren J Moffat Darren.Moffat at Sun.COM wrote:
All of the three that you listed may require changes to the script,
that seems wrong because it is introducing incompatibility between pfksh
and pfksh93 when the longer term goal is that ksh93 become the default.
Now
