On 2021-09-10 23:42, Valerio Messina wrote:
> hi,
> I just substituted the cygnal dll in a my app that start a bash script.
> I got differences in output, so narrowed to the minimum the script.
It seems you have substituted the DLL not only into the app,
but Bash itself, alas.
> Here the results.
>
> Script named D:\installer\cygnal\tst.sh:
>
> export Dir=`pwd`
> echo "cwd:$Dir"
> PATH="."
> echo "PATH1=$PATH"
> export PATH="$Dir/cygroot/bin:$PATH"
> echo "---"
> echo "$PATH"
> echo "---"
> echo "PATH2=$PATH"
> echo "==="
> echo "cwd:$Dir"
> export APP_HOME="$Dir/.app"
> echo "APP_HOME=$APP_HOME"
>
>
> DLL and bash.exe are in ./cygroot/bin
>
> This is the output from windows command.com:
>
> D:\installer\cygnal>cygroot\bin\bash
> bash.exe: warning: could not find /tmp, please create!
> bash-4.4$ ./tst.sh
> cwd:D:/installer/cygnal
Since `pwd` is rendering a path with a drive letter and
backslashes, it's clear that the Cygnal DLL has been
slid underneath it.
I've not validated Cygnal for this use case. (But
I tried it before and remember that warning about
missing /tmp.)
Cygnal could be used as to create a more Windows-native
version of GNU Bash and other utilities.
But it would take much more work than just sliding
a substitute DLL under it.
In fact, this is true for any application. Programs
that have dependencies on POSIX can break. You
have to treat Cygnal as a run-time library with its
own peculiarities and validate your program against
it. Not everything can "magically" work, though a lot of
it can.
For instance, under Cygnal, the PATH environment
variable is semicolon-separated in the Windows way.
A POSIX program which manipulates PATH, and assumes
that it is colon-separated, will malfunction.
That program will have to be maintained if it is
to behave right under both the original Cygwin DLL
and Cygnal. The idea is that this is perfect for someone
who wants that; the developer accepts that the native
PATH is semicolon-separated and is willing to adjust
their program to handle that, in order that it works
in the Windows way.
> /cygroot/bin:.ller/cygnal
This looks like some TTY issue, as if it is
trying to print these two lines:
PATH2=D:/installer/cygnal
/cygroot/bin:.
but the newline is being turned into a carriage
return, and so the second line overwrites the
start of the first:
/cygroot/bin:.ller/cygnal
In other words, not a string processing issue in the
execution of Bash, but a TTY output issue.
Speculation: it could be that "stty onlret" mode is
turned on rather than "stty onlcr": and so newlines
(i.e. ASCII LF characters) output by bash are turning
into CR. Something along those lines.
But, anyway, PATH is semicolon-separated on Cygnal.
Scripts running on a Cygnal-ized shell have to know that
and adjust to it.
Suppose you have a shell that runs well enough on
Cygnal and your script manipulates PATH. That script
has to use semicolons. If the script is to be portable
to regular POSIX, it has to do something like detect
whether it's running on Cygnal or not, and then set
some path_sep variable to either : or ;.
if umame -s | grep -q CYGNAL ; then
path_sep=';'
else
path_sep=':'
fi
kind of thing.
Good luck! Maybe Bash will run well enough to handle
your scripts.
Not sure about how to get it not to print the warning
message about /tmp. Bash contains this code, in shell.c:
#ifdef __CYGWIN__
static void
_cygwin32_check_tmp ()
{
struct stat sb;
if (stat ("/tmp", &sb) < 0)
internal_warning (_("could not find /tmp, please create!"));
else
{
if (S_ISDIR (sb.st_mode) == 0)
internal_warning (_("/tmp must be a valid directory name"));
}
}
#endif /* __CYGWIN__ */
Under Cygnal "/tmp" refers to "X:\tmp" where X is the currently
logged drive. Oops!
Cheers ...
(text/plain)