bug#15150: Possible bug of ln or gfortran of cygwin
I tried to compile following using gfortran 4.8.1-1 include 'bb/test2.f' a(1)=1.0 a(2)=2.0 b=a(1)+a(2) write(6,*) b stop end When bb/test2.f is a real file, no compile error is generated. When aa/test2.f is a real file and bb/test2.f is a symbolic link of /aa/test2.f, Error 'Can't open included file '/bb/test2.f' is displayed. ln -s aa bb was a command to creat symbolic link. The contents of test2.f is dimension a(2) Sincerely yours.
bug#15150: Possible bug of ln or gfortran of cygwin
tag 15150 notabug
close 15150
stop
On 08/21/2013 07:56 AM, Namito wrote:
I tried to compile following using gfortran 4.8.1-1
include 'bb/test2.f'
a(1)=1.0
a(2)=2.0
b=a(1)+a(2)
write(6,*) b
stop
end
When bb/test2.f is a real file, no compile error is generated.
When aa/test2.f is a real file and bb/test2.f is a symbolic link of
/aa/test2.f,
Error 'Can't open included file '/bb/test2.f'
is displayed.
ln -s aa bb
was a command to creat symbolic link.
I doubt a bug in ln.
Notice that above an absolute path of '/bb/test2.f' is reported.
I'd guess that absolute path was incorrectly specified to `ln -s` when creating
the link,
or more unlikely that gfortran is handling relative symlinks incorrectly.
You can exclude gfortran by doing something like:
(cd bb { test -e test2.f echo 'link ok'; })
Generally one should send the ln --version when reporting bugs.
thanks,
Pádraig.
bug#15157: join doesn't follow norms and dies instead of doing something useful w/duplicate options
join is inconsistent with other utils (like cut, for example) in how it handles a specification of a switch value that has already been set. 1) if a switch is set more than once with the same value, it doesn't complain, but if the options differ, unlike utilities like 'cut', the tool dies rather than taking the final specification as what is meant. ex: cut -d'TAB' -d: -f1 /etc/passwd doesn't issue any errors. But the same thing with join: join -t'TAB' -t: -f1 /etc/passwd /etc/group join: incompatible tabs ??? tabs? they are field separators. Historically, options specified on the command line take precedence over options in an init/rc-file or in the ENV. Many utils in a build process build up command lines in pieces -- with the expectation that later values take precedence, allowing for higher level make files to set defaults, while allowing make's in sub directories to override options set in a parent. Defaulting to fail, rather than proceed with latest input data, is rarely useful for humans. It's arguable whether or not it is useful for machines in most cases. In the past, unix utils have tried to do what the user meant rather than deliberately playing stupid and pretending to have no clue about what was likely expected.
bug#15157: bug#15158: sort complains about incompatible options (that aren't) AND when it shouldn't
The -g and -h options of 'sort' are indeed incompatible; they result in different outputs. More generally, these bug reports reargue the 'grep' bug reported here: http://lists.gnu.org/archive/html/bug-grep/2013-08/msg00017.html and replied to here: http://lists.gnu.org/archive/html/bug-grep/2013-08/msg00018.html Generally speaking, the GNU utilities follow the POSIX utility syntax guidelines, in particular Guideline 11: The order of different options relative to one another should not matter, unless the options are documented as mutually-exclusive and such an option is documented to override any incompatible options preceding it. http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap12.html#tag_12_02 It sounds like you're disputing the main part of this guideline and are advocating always taking the second (exceptional) part. It's not clear to me that this makes sense, and there are good arguments for sticking with the more-cautious approach.
bug#15157: bug#15158: sort complains about incompatible options (that aren't) AND when it shouldn't
Paul Eggert wrote: The -g and -h options of 'sort' are indeed incompatible; they result in different outputs. More generally, these bug reports reargue the 'grep' bug reported here: http://lists.gnu.org/archive/html/bug-grep/2013-08/msg00017.html --- Not really. There was nothing about the similarity and overlap of sort options and how integer is still in the class of general numbers, which includes 'e' as an abbreviation for a power prefix, just like KMG are power prefixes as well. You can't claim that 3.2e+3, where e indicates some power of 10 follows, and is used as a scaling factor for 3.2 is that different from 3.2k, where k is a scaling factor, and, indicates that 3.2 is scaled by a factor of 10**3. They are both general numeric cases... I don't think I had anything to say, at all, about the overlap of such in grep, which is inconsistent with itself: grep -d read -d skip --color=auto --color=always foo (no error)... GREP_OPTIONS=-d skip --color=auto -P grep -E this|that grep: conflicting matchers specified ??? I didn't specify them on the command line -- OR now: egrep this|that egrep: egrep can only use the egrep pattern syntax But I didn't specify any other syntax... oh.. it reads the cmdline options of 'grep', but it can't function like grep? That sounds a bit ill-designed. --- Please don't try to take over and confused bugs on other utils, just to put forth your view that utilities should default to broken unless the user invokes them perfectly. That's a bad User Interface design -- computers are supposed to be there to help us -- not to enable those who enjoy making others wrong to do so on a wide scale. and replied to here: http://lists.gnu.org/archive/html/bug-grep/2013-08/msg00018.html Generally speaking, the GNU utilities follow the POSIX utility syntax guidelines, in particular Guideline 11: The order of different options relative to one another should not matter, unless the options are documented as mutually-exclusive and such an option is documented to override any incompatible options preceding it. http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap12.html#tag_12_02 It sounds like you're disputing the main part of this guideline and are advocating always taking the second (exceptional) part. --- The 2nd part has been the norm. While you are claiming that the exceptional design should be the norm. Let me know how specifying your options out of order on gnu tar works out... There are many contexts where one option enables or disables others. The idea that options should be order independent is as absurd as the idea that the lines in a C program should also be order independent. This is a perfect example of the ivory tower thinking that is dominating POSIX now. While they used to be more practical and describe what was, now they've jump to the forefront to dictate bad design and dumbed-down interfaces. Have you ever thought about the fact that they are funded by Corporations who might have an interest in seeing Linux's open nature be killed off -- and/or it's usage reduced? It's not clear to me that this makes sense, and there are good arguments for sticking with the more-cautious approach. So you have said, but name some that would be true for most people and make more sense than the previous, deterministic approach... As it is, I could point to sources by them and talk about what they said and everyone knows... to make my point, but I'll rely on the common sense that most people have in knowing that having programs that are resilient in the face of odd user input and have it do something useful and predictable is far better than having fragile programs that break on all but perfect input.
bug#15150: Possible bug of ln or gfortran of cygwin
(2013/08/21 23:11), Pádraig Brady wrote:
tag 15150 notabug
close 15150
stop
On 08/21/2013 07:56 AM, Namito wrote:
I tried to compile following using gfortran 4.8.1-1
include 'bb/test2.f'
a(1)=1.0
a(2)=2.0
b=a(1)+a(2)
write(6,*) b
stop
end
When bb/test2.f is a real file, no compile error is generated.
When aa/test2.f is a real file and bb/test2.f is a symbolic link of
/aa/test2.f,
Error 'Can't open included file '/bb/test2.f'
is displayed.
ln -s aa bb
was a command to creat symbolic link.
I doubt a bug in ln.
Notice that above an absolute path of '/bb/test2.f' is reported.
I'd guess that absolute path was incorrectly specified to `ln -s` when creating
the link,
or more unlikely that gfortran is handling relative symlinks incorrectly.
You can exclude gfortran by doing something like:
(cd bb { test -e test2.f echo 'link ok'; })
Generally one should send the ln --version when reporting bugs.
thanks,
Pádraig.
Let me make one correction af first.
When aa/test2.f is a real file and bb/test2.f is a symbolic link of
aa/test2.f,
Error 'Can't open included file '/bb/test2.f'
is displayed.
link ok
was displayed when I did,
(cd bb { test -e test2.f echo 'link ok'; })
Also, version of ln is 8.15
bug#15158: sort complains about incompatible options (that aren't) AND when it shouldn't
tag 15158 notabug close 15158 stop On 08/21/2013 10:57 PM, Linda Walsh wrote: If I tell sort to do a general numeric sort and interpret human suffixes, such as sort -gh ... sort fails similarly, if I ask it to sort by numeric size and respect human suffixes: sort -nh sort claims: sort: options `-dn' are incompatible similarly, numeric and general numeric are claimed to be incompatible -- how is that? Regardless of compatibility or not, sort doesn't use even use _1_ of the options that were specified. If it always used the latest option specified as other utils, it would still behave in a deterministic manner, and give correct output in the majority of cases (if not, then state the question)... I don't know which utils have been dumbed down to fail on, any, ambiguous input (if it is ambiguous, which I argue, it is not -- as there is a prescribed order for evaluation), but the emphasis on computer programs not being resilient. Rigidly making people wrong and refusing to work unless they ask you in the exact right language/syntax is a step backwards for computer programs. The idea on computers is to make life easier -- and enforcing the user to create odd workarounds when the program could have gotten it right, feels like user-abuse. So for these comparison options, it's not obvious what's going on in the implementation. One might think that if -dn was specified, that something like dictionary was used and then numeric done to break ties. Similary with -gh, one might think that -h was an adjustment to -g rather than being a _separate_ comparison method entirely. The errors are imparting this info to the user. Given the complexity of the option combinations for sort(1) in particular, it's important to do so. The edge case of a default sort invocation using for example -d, which is then overridden with -n through config, is not usual, and thus should not proceed, for the reason above. Now you have a point about non mutually exclusive args, which I'll respond to in the related bugs you opened. thanks, Pádraig.
bug#15157: join doesn't follow norms and dies instead of doing something useful w/duplicate options
Pádraig Brady wrote: On 08/21/2013 10:44 PM, Linda Walsh wrote: Historically, options specified on the command line take precedence over options in an init/rc-file or in the ENV. Many utils in a build process build up command lines in pieces -- with the expectation that later values take precedence, allowing for higher level make files to set defaults, while allowing make's in sub directories to override options set in a parent. Defaulting to fail, rather than proceed with latest input data, is rarely useful for humans. It's arguable whether or not it is useful for machines in most cases. In the past, unix utils have tried to do what the user meant rather than deliberately playing stupid and pretending to have no clue about what was likely expected. Right, to support subsequent specification of scripts etc. it's useful to allow options to be overridden. In addition this is how other systems behave wrt to input field separator options for example. Now on the other hand, the ambiguity being diagnosed here in such an obtuse manner, is that one might think that _any_ of the specified separators are supported in the input, rather than the last taking precedence. There are other utilities not all officially under the official 'coreutils' project, but definitely under the core unix utilities definition. One of those which started me looking at the inconsistencies was/is grep(+flavors). There, you have the ENV var GREP_OPTIONS, which I would argue should take the least precedence when compared with the 'command name' and 'options on the command line' The -[FEPG] options are mutually exclusive and can easily override each other w/o harm. To add spice, egrep, uses the 'GREP_OPTIONS', but isn't really compatible with 'grep' (as it is now) w/regards to -- for example, the search-type switches. I'm not sure why, but egrep, right now, refuses all pattern options --this is a real kicker: egrep -E foo egrep: egrep can only use the egrep pattern syntax Ok, thank you for sharing, but doesn't '-E' mean egrep pattern syntax? That even, '-E' fails, telling the user that they can only use the syntax they are specifying seems abusive. That other options in grep DO take the 'last' option, but the syntax options are disallowed, is inconsistent, unuseful and creates breakages in existing scripts that don't know they should clear GREP_OPTIONS in order for egrep and fgrep to function correctly. There is no reason why last specified shouldn't apply there as well (with the ENV being specified before the command was entered, thus having lowest priority), the command name being the 2nd thing typed, and having next priority, and options specified to the command being the last thing typed, left to right. It so happens that 'join' was used as a justification for this behavior in 'grep', which was one of the reasons why I looked at join (along with sort, and a few others) to note where there might be inconsistencies and whether or not the trend of fail taking precedence over deterministic and working behaviors that have been defined as normal for as long as I can remember on *nix. Do you see a reason why grep(+e/f) should fail -- or, especially, why e/fgrep should fail due to conflicting options in a GREP env var... or reject specification of a correct format? New users of these tools may be caught out though. --- They wouldn't have any previous history to be caught by. When I came to *nix, I read the man page and noted that nearly all of the utilities showed the same behavior (with the exception of sort that might have it's options confused as applying to different fields, not sure how likely that is). I have come to rely on option-override working in a number of utils -- with config files taking the lowest priority (they are present before the user logs in), followed by ENV vars (set each session), command name and switches...(usually command name isn't part of that list, but to make things consistent...) We could display a warning but that would negate most of the benefit of allowing overriding the option. I suppose we could support --debug on all utils to diagnose ambiguities like this, rather than disallowing them. I'll look at doing both of the above. --lint? debug has other connotations... or --anal^h^h^h^hstrict ? ;^) thanks, Pádraig. -- ditto.. and I need to know how to phrase the problem for the kernel folks as they have quite a few places calling grep where they don't check for status (let alone, now being affected by conflicting options)... Could 15127 also be re-opened as it was closed unilaterally in the presence of obvious bugs. Thanks...
