[Info-vax] Looking into C-include files on VMS

[John E. Malmberg]

Joerg Schilling wrote:
> In article <OgLGm.108497$5n1.85640 at attbi_s21>,
> John E. Malmberg <wb8tyw at qsl.network> wrote:
> 
>> I just replaced the bash/sh programs with the ones that I use instead of 
>> the ones in the kit.  Those fixes were suppose to be in HP kit that I 
>> installed on Eisner, but apparently are not.
> 
> This version of the shell indeed fix the problems with the non-working
> "here documents". It did however introduce a new problem:
> 
> configure calls test -r somefile (using a well known file name for "somefile")
> in order to verify that it was called from the right directory. While
> the old bash version did work correctly with this test, the current bash
> returns exit code 1 for the built in command "test" in this case.
> I found a workaround for this problem: after I called "chmod a+r *",
> test -r somefile again returns exit code 0 for the existing files
> that are owned by me. It seems that the current bash version looks for the
> wrong "r" bit in the stat.st_mode field.

I seem to remember seeing that, but other than working around it, I do 
not have a solution.

>>> As "bash" also from time to time hangs while exeuting similar code
>>> as mentioned above, this I/O redirection problem currently seems to be 
>>> the only problem for getting "configure" to work.
>> This may also solve that problem.  There are still some intermittant 
>> hangs that I have not found the causes for.
> 
> This currently seems to be only problem that cannot be worked around by me.
> I am using one configure script for all my software (330000 lines / 8 MB
> of code), so I have 650 different tests in configure. As there is no way to 
> restart a configure run, I would need to be able to completely finish
> all test without a hang. 
> 
> Maybe this helps: After I retried to call configure several times, I get 
> this error:
> 
> bash$ CC=cc CONFIG_NOFAIL=TRUE sh ./configure
> ./configure: Can't make pipes for command substitution!
> configure: error: can not find sources in  or ..
> 
> restarting the current interactive bash temporarily fixes the problem.

Looks like a resource leak in bash.

Spawning sub-shells is expensive on VMS, the less cases of bash running 
another bash as a child that can be done, the better.

I have sent an e-mail to Dale Coy about raising the number of files that 
a process can have open, which looks like the error that you are 
hitting.  The default on Encompasserve.org is 400.  A home I run with 4096.

> In case that bash hangs, there are commands from "confiure" keeping hanging
> around (e.g. grep) that go away if I finish the current interactive shell.

This could be a quota issue.

There is also a bug related to use of an external "echo" commmand 
instead of the built in that I discovered this year.  I have not chased 
down why this is happening, but using the external "echo" command in a 
configure script results in internal data corruption in bash.

Another issue is simply that except for the GNV bash, the other programs 
still either use the C library pipes, which do not behave like UNIX 
pipes, or they use temporary files as pipes.

I am aware of a company that is looking at fixing the bugs in GNV bash. 
  I do not know what progress they have made.

Currently it will probably be a few months before I can look at making 
any code changes to GNV again.

-John
wb8tyw at qsl.network
Personal Opinion Only