So I submitted
6876704 "wx putback" not compatible with ksh93
as a bug against the wx tool. Until it shows up externally, the
description reads
When I tried to run "wx pb -p /ws/sfwnv-gate -n" this morning to test a
putback to the SFW gate, I got
putback: User dduvall does not have access to putback to workspace
"/ws/sfwnv-clone" (Error 2065)
which was odd, because I explicitly told it to use the gate path, not
the clone. When I reparented and tried the command again without the
-p, it started to do a real putback, having apparently ignored the -n.
I seem to have ^Ced it before anything untoward happened, but it was a
bit of a scare.
As far as I can tell, the construct that wx uses in wx_putback() to
collect arguments to pass to $PUTBACK isn't compatible with ksh93 --
that is, pbargs[${#pbar...@]}]="-$i" doesn't actually do anything to
$pbargs.
I suppose it's possible this is a ksh93 bug, but I'm not sure. Whether it
is or not, is there a construct that's safe to use here both for ksh88 and
ksh93? It's not clear to me why $pbargs is an array rather than a string,
unless there's some expectation that the path to the parent workspace might
have a space in it (which is why I'm copying Will).
Thanks,
Danek
