[PATCH] changes for cygwin build

[Qian Yun]

This patch improves the cygwin build a bit.

First, like ecl on windows, the "(require 'cmp)" part is
now optional.

Second, for unknown reason, when calling "./FRICASsys"
under cygwin, "DIRECTORY_-NAMESTRING" returns "" instead of
"./", so I add a call to change it to absolute path first.

Finally, not included in this patch, the last test in
files.input, it fails under cygwin, because in github actions
windows runner, it is run with admin user, so the emulated
cygwin environment has root permission. That test could
also fail under linux if some distribution decides to build
and run test under root. Is there a clean way to workaround
it?

- Qian

[Waldek Hebisch]

On Sat, Aug 01, 2026 at 09:34:26PM +0800, Qian Yun wrote:
> This patch improves the cygwin build a bit.
>
> First, like ecl on windows, the "(require 'cmp)" part is
> now optional.

Lack of cmp is not nice (gcc is has Cygwin package so lack
of GCC in not a good excuse). But OK.

> Second, for unknown reason, when calling "./FRICASsys"
> under cygwin, "DIRECTORY_-NAMESTRING" returns "" instead of
> "./", so I add a call to change it to absolute path first.

What about using 'filename_directory' instead?

> Finally, not included in this patch, the last test in
> files.input, it fails under cygwin, because in github actions
> windows runner, it is run with admin user, so the emulated
> cygwin environment has root permission. That test could
> also fail under linux if some distribution decides to build
> and run test under root. Is there a clean way to workaround
> it?

I admit that failures like that for me are one more reason
not to run normal programs under root account. I wonder
if under cygwin we can change user to a normal one (under Unix
root can 'su' to any user and run with changed permissions).

--
Waldek Hebisch

[Qian Yun]

On 8/1/26 10:10 PM, Waldek Hebisch wrote:
> On Sat, Aug 01, 2026 at 09:34:26PM +0800, Qian Yun wrote:
>> This patch improves the cygwin build a bit.
>>
>> First, like ecl on windows, the "(require 'cmp)" part is
>> now optional.
>
> Lack of cmp is not nice (gcc is has Cygwin package so lack
> of GCC in not a good excuse). But OK.
>
>> Second, for unknown reason, when calling "./FRICASsys"
>> under cygwin, "DIRECTORY_-NAMESTRING" returns "" instead of
>> "./", so I add a call to change it to absolute path first.
>
> What about using 'filename_directory' instead?
>

Is 'filename_directory' a typo here? Can't find it.

>> Finally, not included in this patch, the last test in
>> files.input, it fails under cygwin, because in github actions
>> windows runner, it is run with admin user, so the emulated
>> cygwin environment has root permission. That test could
>> also fail under linux if some distribution decides to build
>> and run test under root. Is there a clean way to workaround
>> it?
>
> I admit that failures like that for me are one more reason
> not to run normal programs under root account. I wonder
> if under cygwin we can change user to a normal one (under Unix
> root can 'su' to any user and run with changed permissions).
>

Using 'su' seems heavy to me.

I have a workaround: after changing the permission, try to
delete it. For root, it can be deleted despite 400 permission.
Then the following "openIfCan" is failed as expected, but for
a different reason.

We need something like:
)system (mkdir bar; touch bar/foo.out; chmod 400 bar/foo.out)
)system (chmod 500 bar/; rm bar/foo.out)

- Qian

[Waldek Hebisch]

On Sun, Aug 02, 2026 at 10:16:28AM +0800, Qian Yun wrote:
> On 8/1/26 10:10 PM, Waldek Hebisch wrote:
> > On Sat, Aug 01, 2026 at 09:34:26PM +0800, Qian Yun wrote:
> >> This patch improves the cygwin build a bit.
> >>
> >> First, like ecl on windows, the "(require 'cmp)" part is
> >> now optional.
> >
> > Lack of cmp is not nice (gcc is has Cygwin package so lack
> > of GCC in not a good excuse). But OK.
> >
> >> Second, for unknown reason, when calling "./FRICASsys"
> >> under cygwin, "DIRECTORY_-NAMESTRING" returns "" instead of
> >> "./", so I add a call to change it to absolute path first.
> >
> > What about using 'filename_directory' instead?
> >
>
> Is 'filename_directory' a typo here? Can't find it.

Sorry, I mean 'file_directory'

> >> Finally, not included in this patch, the last test in
> >> files.input, it fails under cygwin, because in github actions
> >> windows runner, it is run with admin user, so the emulated
> >> cygwin environment has root permission. That test could
> >> also fail under linux if some distribution decides to build
> >> and run test under root. Is there a clean way to workaround
> >> it?
> >
> > I admit that failures like that for me are one more reason
> > not to run normal programs under root account. I wonder
> > if under cygwin we can change user to a normal one (under Unix
> > root can 'su' to any user and run with changed permissions).
> >
>
> Using 'su' seems heavy to me.
>
> I have a workaround: after changing the permission, try to
> delete it. For root, it can be deleted despite 400 permission.
> Then the following "openIfCan" is failed as expected, but for
> a different reason.
>
> We need something like:
> )system (mkdir bar; touch bar/foo.out; chmod 400 bar/foo.out)
> )system (chmod 500 bar/; rm bar/foo.out)

_That_ looks heavy for me. But if using 'su' is not workable for
some reason, then it is OK.

--
Waldek Hebisch

[Qian Yun]

On 8/2/26 6:46 PM, Waldek Hebisch wrote:
>>>
>>>> Second, for unknown reason, when calling "./FRICASsys"
>>>> under cygwin, "DIRECTORY_-NAMESTRING" returns "" instead of
>>>> "./", so I add a call to change it to absolute path first.
>>>
>>> What about using 'filename_directory' instead?
>>>
>>
>> Is 'filename_directory' a typo here? Can't find it.
>
> Sorry, I mean 'file_directory'
>

Yes, this works. I've tested various binaries for it.

>>>> Finally, not included in this patch, the last test in
>>>> files.input, it fails under cygwin, because in github actions
>>>> windows runner, it is run with admin user, so the emulated
>>>> cygwin environment has root permission. That test could
>>>> also fail under linux if some distribution decides to build
>>>> and run test under root. Is there a clean way to workaround
>>>> it?
>>>
>>> I admit that failures like that for me are one more reason
>>> not to run normal programs under root account. I wonder
>>> if under cygwin we can change user to a normal one (under Unix
>>> root can 'su' to any user and run with changed permissions).
>>>
>>
>> Using 'su' seems heavy to me.
>>
>> I have a workaround: after changing the permission, try to
>> delete it. For root, it can be deleted despite 400 permission.
>> Then the following "openIfCan" is failed as expected, but for
>> a different reason.
>>
>> We need something like:
>> )system (mkdir bar; touch bar/foo.out; chmod 400 bar/foo.out)
>> )system (chmod 500 bar/; rm bar/foo.out)
>
> _That_ looks heavy for me. But if using 'su' is not workable for
> some reason, then it is OK.
>

This version does not work, because simply removing the file does
not prevent openIfCan to recreate it, test should remove directory
instead. This is a bit complicated, and I intend to leave it alone
for now, because I have no intention to add the ecl on cygwin to
CI right now, which takes 5 hours to finish.

- Qian