Path: csiph.com!optima2.xanadu-bbs.net!xanadu-bbs.net!news.glorb.com!usenet.stanford.edu!not-for-mail
From: aixtools <aixtools@gmail.com>
Newsgroups: gnu.bash.bug
Subject: Re: Bash 4.3.30 on AIX 6.1 filename completion
Date: Wed, 12 Aug 2015 12:42:29 +0200
Lines: 58
Approved: bug-bash@gnu.org
Message-ID: <mailman.8186.1439376159.904.bug-bash@gnu.org>
References: <55BEBADE.8030108@goshawk.com> <55BF6F47.7090405@case.edu> <55CB220A.3060301@gmail.com>
NNTP-Posting-Host: lists.gnu.org
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
To: bug-bash@gnu.org
Envelope-to: bug-bash@gnu.org
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
In-Reply-To: <55CB220A.3060301@gmail.com>
Precedence: list
Xref: csiph.com gnu.bash.bug:11326

On 2015-08-12 12:38 PM, aixtools wrote:
> On 2015-08-03 3:40 PM, Chet Ramey wrote:
>> On 8/2/15 8:50 PM, Steve Dahl wrote:
>>> If on AIX 6.1, I mount an NFS volume exported from CentOS 6.7, Bash
>>> (4.3.30) is unable to do tab completion within that file system. If 
>>> (for
>>> example) I search for files that I know exist, such as:
>>>
>>>      ls -l /path/to/files/*.h
>>>
>>> ...no answers are returned even though
>>>
>>>      ls -l /path/to/files
>>>
>>> ...will show those files.
>>>
>>> In the course of trying to understand why AIX didn't like our new NFS
>>> server, I found that bash's glob.c depends on opendir(), and that in a
>>> simple test on that NFS file system, opendir() fails with EOVERFLOW.
>>>
>>> The AIX man page for opendir() documents opendir64() but doesn't go 
>>> into a
>>> lot of detail about what it's for other than the inferred hint that it
>>> might allow for file sizes larger than 4 GB.
>>>
>>> The same simple test that gets EOVERFLOW when I use opendir() indeed 
>>> seems
>>> to succeed when I use opendir64(). Once you know the answer, you can 
>>> find
>>> hints on IBM forums that seem to confirm it.
>>>
>>> Is there already a version of "bash" somewhere that already supports 
>>> large
>>> file systems on AIX if its compilation is configured right?
>> Bash and Readline don't use opendir64/readdir64 directly.  You might be
>> able to get it to work by using cpp defines in lib/readline/complete.c
>>
>> Chet
> Actually, I am working on a "scandir" program myself, where I am using 
> opendir(). The simpliest approach seems to be this at the start of the 
> code, i.e., before ANY include files are inserted. One of it's effects 
> is to make all opendir() calls automatically convert to opendir64() - 
> no code changes needed, and the code works on both AIX - and debian 
> (Linux on Power) that I have tested.
>
> /*
>  * define _LARGE_FILES needs to be first so that all the include files 
> know that
>  */
> #ifdef _AIX
> #define _LARGE_FILES
> #endif
>
> Hope this helps!
p.s. - rather than actually add this to ALL source files, adding 
-D_LARGE_FILEs to CPP_FLAGS and/or to CFLAGS is probably the better 
approach.