Custom Query (245 matches)

The EMXSHELL is used to override COMSPEC for popen() and system() calls in kLIBC. The order of checking in the first case is EMXSHELL, COMSPEC and in the second — EMXSHELL, COMSPEC, OS2_SHELL, SHELL.

At the same time, many scripts in the unix environment (e.g. configure scripts) use SHELL to override the shell command to use. However, given that in the first case SHELL isn't used at all and in the second case it's checked after EMXSHELL and COMSPEC, even if the script sets SHELL (e.g. to point to sh.exe), kLIBC will not notice this and will still use the value of COMSPEC (which is usually cmd.exe). Not quite what the scripts expect.

I think it makes sense to check for SHELL before checking for EMXSHELL or COMSPEC. The order should be the same in both calls: SHELL, EMXSHELL, COMSPEC, OS2_SHELL.

The patch is trivial (in files lib/io/popen.c and lib/process/system.c) so not attaching it here.

There are a several inconsistencies in the functionality of the built-in path rewrite rule that is used to support Unix-like file system structure (to simplify porting of Unix software to OS/2) by replacing /@unixroot with the value of the UNIXROOTenvironment variable.

This is a meta-ticket to put all separate tickets related about inconsistency together.

Currently, in order to better support the Unix-like file system structure (which in turn simplifies porting of many Unix software to OS/2) the /@unixroot path rewrite rule is used. This pseudo-path is replaced with the value of the UNIXROOT environment variable which makes it possible to move the Unix file system from drive to drive w/o breaking software.

However, this technique still requires one change to the original Unix sources: you have to replace each / which is meant as the root of the Unix file system tree along the sources and makefiles with /@unixroot. This is quite annoying (as there may be dozens of places where this change is needed) and error prone (you may forget one place and this will break everything).

I suggest to extend UNIXROOT support by changing the path rewriter so that it will always treat paths starting with / as Unix-like paths and therefore replace / with the value of UNIXROOT. This will eliminate the need of prepending /@unixroot to them. In theory, many programs should just build and work out-of-the-box.

The only thing that we will lose with such a change is the original meaning of / as a reference to the root directory of the current drive. Though I don't think that this feature is really used by any software, it may be expected by the end user. So it sounds reasonable to make it optional (and even off by default).