On 6/14/14 10:28, Paul Eggert wrote:
That part of POSIX has been standardized since POSIX.2 (IEEE Std
1003.2-1992), and the wording hasn't changed since then if I recall
correctly, so AIX has had this conformance bug for decades and nobody
has cared
I just ran into a related problem when
tags 17774 notabug
close 17774
stop
(triaging old bugs)
On 18/06/14 12:30 PM, Michael Felt wrote:
revisted my 8.15 package in detail. Seems that two years ago I had already
done something special for coreutils - so my apology - not a bug, just
something in the way. I will find a way to make it
revisted my 8.15 package in detail. Seems that two years ago I had already
done something special for coreutils - so my apology - not a bug, just
something in the way. I will find a way to make it transparent for installp.
My question: once done, would you be interested in what I have done to
incl
Well, you guys are the experts. I was trying to be "smart" - thinking that
lbracket 'required' the closing right bracket to keep the shell syntax
checkers happy. Maybe I am expecting too much from my shells need to check
syntax.
FYI - It seems to be working as expected, rather designed - so I shal
On 06/17/2014 02:50 PM, Michael Felt wrote:
> FYI: the program runs fine, and even from the command line (the extra ] at
> the end must satisify the ksh syntax checking).
Rather, the 'test' binary and the 'lbracket' binary differ in one
crucial aspect: 'lbracket' requires its last argument in argv
FYI: the program runs fine, and even from the command line (the extra ] at
the end must satisify the ksh syntax checking).
Note: the 8.15 one is "suppossed" to fail, because I packaged that on AIX
6.1 - and then it does not work on AIX 5.3.
root@x093:[/data/prj/gnu/coreutils]find . -name ? -ls
85
then if nobody has cared up til now I doubt I will have much chance of
making a difference on that.
thx for the correction. I will mention it, but will not be holding my
breath.
Michael
On Jun 14, 2014 7:28 PM, "Paul Eggert" wrote:
> Michael Felt wrote:
>
>> this is a standard with 2008 in it's
Michael Felt wrote:
this is a standard with 2008 in it's name, and
AIX 5.3 is from 2004
AIX 5.3 is no longer supported, so I wouldn't bother filing a bug for
it. I was thinking about AIX 7.1, which has the same problem; if you
want to be a POSIX nerd you can file a bug report against it.
T
I believe IBMis usually quite commited to being inline with published and
accepted standards. However, this is a standard with 2008 in it's name, and
AIX 5.3 is from 2004, and the TL/SP level I am compiling on, for backwards
compatibility is dated 2007 - so hard to complain that it is not up to a
2
Yes, I suppose I could just delete it. However, my comment is "also" that
at 8.15 it packaged fine. Starting with 8.17 (or maybe 8.16, I can download
and try).
FYI - I can execute the program [ (as ./? --version as the shell does not
like [ entered directly, and I am not counting the backslashes c
Michael Felt wrote:
But to have a name like that, I must be too old fashioned -
where is the win?
It's so that execlp ("FOO") acts like the shell command FOO, or, more
precisely, so that the attached C program works like '[ -d / ]' at the
shell level. POSIX requires that all standard utiliti
I know now why I am still using version 8-15
1. I never tried 8.16
2. since version 8.17 (or 16 which I never tried) lbracket gets linked as
the program [
Now, except that I would have a terrible time entering that as a command,
as is it a special character for ksh, and I would think bash the addi
12 matches
Mail list logo
