Re: [Jython-dev] updated javaos.py

[Kevin B. <kev...@bi...>]

Finn Bock wrote:

> [Kevin]
>
> [In cygwin I had actually enter ctrl-M ctrl-J at the command prompt to
> include a CRLF in the output of "cmd.exe /c set"]

What I've been doing is typing:

export X='asdf

zxcv'


> So it seems like "cmd.exe /c set" is loosing the significant embedded
> newline. Is this also the case for "sh -c env" on unixes? I suspect it
> is.

Yes - both "cmd.exe /c set" and "sh -c env" output the same, broken way.  :-(

> It appears that the bash builtin "set" command writes its output in a
> way that can be used for input. So while commands we execute now must
> remain the portable default, we could have a mode that uses "bash -c
> set" and convert the output back into real values:
>
>   X=$'My\nPATH=Kevin'
>
> It seems it would have to deal with the $'..' and backslash quoting.

On my cygwin system (bash 2.02.1(2)), bash -c set outputs:
X='asdf
zxcv'
(no the $ or backslash escapes), but my Linux system (bash 2.05.0(1)) outputs as
you described.

Easy enough to add a 'gnu' os type that does 'bash -c set', but the quoting
requires a rewrite of _getEnvironment (or a subclass of _ShellEnv) - probably
read the whole file, us re.split/findall to parse it out, and ??? to unescape the
escaped chars, and maybe something to handle the $/no$/escaped-chars.  Yuck.

>It is not a requirement to fix this far-fetched problem before beta1.

Yes - I don't think the niche of 'gnu users using multi-line environment
variables that have equal signs in lines after the first' is big enough to worry
about it at this point...  (Anyone who disagrees is welcome to implement it...
:-)  )

kb