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

[Joerg Schilling]

In article <hDZGm.109482$5n1.40708 at attbi_s21>,
John E. Malmberg <wb8tyw at qsl.network> wrote:

>> 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.

If I check the whole source, I need to run chmoe a+r many times.


>> 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.

I would guess that bash this is related to the left over files
$HOME/sh*. Maybe bash does not close the pipes.

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

Running configure is expensive on some architectures but the schily 
makefilesystem has a make rule that checks whether it is needed to run 
configure, so it is usually only run once.

>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.

Yes, ulimit in bash shows me 400 may open files.

>> 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.

It also hangs on disks without quotas.

>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.

configure does never call /bin/echo

>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.

There is currently the chance to work at two places in an independent
way.

Being able to successfully run "configure" will create a complete list
of features while the current hand crafted static feature list made by
Eberhard Heuser-Hofmann and Steven M. Schweda only contains parts of
the usable features.

Being able to control compilation by "make" will even help with the static
configuration. The current state of smake looks very promising as it seems
to work correctly except that it cannot yet call programs via bash.
GNU make may be able to call commands via bash but is otherwise full
of bugs and does not work correctly as it's internal string processing 
does not work. In case someone is interested: any gmake version before
3.81 will not work because of bugs in gmake.

I am sure, that for a person who knows VMS, it should not be hard to 
change the smake code to allow smake to call commands via bash.

-- 
EMail:joerg at schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
      js at cs.tu-berlin.de		(uni)  
      joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL:  http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily