Description of problem: In : bash-3.2-29.fc10.i386 bash-4.0-rc1.1.fc11.i386 LANG=C man bash says: ----------------------------------------- source: ...... When bash is not in posix mode, the current directory is searched if no file is found in PATH. ----------------------------------------- However with man-pages-ja-20081015-1.fc10, man bash says (in ja_JP): ----------------------------------------- source: ...... bash が posix モードで動作していれば、PATH 中でファイルを見つ けられなかった場合には、カレントディレクトリが検索されます。 ----------------------------------------- This is quite opposite. Actually with bash-4.0-rc1.1.fc11: ----------------------------------------- $ rpm -q bash bash-4.0-rc1.1.fc11.i386 $ ls -al eval.sh -rw-r--r-- 1 tasaka1 tasaka1 323 2009-01-27 21:59 eval.sh $ sh -c ". eval.sh" sh: line 0: .: eval.sh: file not found ----------------------------------------- i.e. in posix mode source in sh does not search for the current directory any more
That tidbit is messing up seriously quite a chunk of a startup and surely a lots of stuff "out in the field".
(In reply to comment #0) > Description of problem: > In : > bash-3.2-29.fc10.i386 > bash-4.0-rc1.1.fc11.i386 > LANG=C man bash says: > ----------------------------------------- > source: > ...... > When bash is not in posix mode, the current directory is > searched if no file is found in PATH. > ----------------------------------------- > > However with man-pages-ja-20081015-1.fc10, man bash > says (in ja_JP): > ----------------------------------------- > source: > ...... > bash が posix モードで動作していれば、PATH 中でファイルを見つ > けられなかった場合には、カレントディレクトリが検索されます。 > ----------------------------------------- > This is quite opposite. What is the opposite? The en/ja man page descriptions, or the command behaviour? > Actually with bash-4.0-rc1.1.fc11: > ----------------------------------------- > $ rpm -q bash > bash-4.0-rc1.1.fc11.i386 > $ ls -al eval.sh > -rw-r--r-- 1 tasaka1 tasaka1 323 2009-01-27 21:59 eval.sh > $ sh -c ". eval.sh" > sh: line 0: .: eval.sh: file not found > ----------------------------------------- > i.e. in posix mode source in sh does not search for the current > directory any more sh is posix mode, so the above is correct. $ sh -c ". eval.sh" sh: line 0: .: eval.sh: file not found $ bash -c ". eval.sh" $
(In reply to comment #1) > That tidbit is messing up seriously quite a chunk of a startup and surely a > lots of stuff "out in the field". This seems to be an man page issue, not an issue with binaries. The "messing up" is likely something else.
(In reply to comment #2) > What is the opposite? The en/ja man page descriptions, or the command > behaviour? Please check the title and the component of this bug report :)
(In reply to comment #4) > Please check the title and the component of this bug report :) Yep, and that's why I've changed the severity down.
> Yep, and that's why I've changed the severity down. In my understanding the severity is not in discrepancies of assorted variants of manpages but it lies in a potential breakage of various scripts which were written and deployed "locally". Changes in API, and this is one, should not be taken lightly. It is true that it not hard to fix those, if you realize what happened, but so far at least scripts used by /etc/init.d/network broke and, AFAIK, they are still broken.
(In reply to comment #6) > In my understanding the severity is not in discrepancies of assorted variants > of manpages but it lies in a potential breakage of various scripts which were > written and deployed "locally". Changes in API, and this is one, should not be > taken lightly. > > It is true that it not hard to fix those, if you realize what happened, but so > far at least scripts used by /etc/init.d/network broke and, AFAIK, they are > still broken. I'm not sure how that breakage is related to the mistranslation in Japanese manpages since they could see difference between the description in manpages and the actual behavior before pushing something to public though, translations is always likely to be mistranslated or be inconsistent translations comparing to the original one by changing APIs etc, because upstream doesn't maintain it. particularly in the case of documentations and manpages not using something like gettext to detect changes in the original one. I don't think a kind of this issue is a higher-serverity so that there are a workaround to see a behavior i.e. looking at the English manpages.
> I'm not sure how that breakage is related to the mistranslation in Japanese Do you want to say that during a startup when a breakage occures bash is in a posix mode? I am not sure how but it appears that we are talking about two different things. I understood the original report that something got mixed up.
To make this bug more clearer: * As I said in comment 0 Japanese man pages for bash need fixing. I am not saying that bash binary should be fixed. * What became critical now is that Japanese bash man page says that *in* posix mode source command _does_ search current path. This was not a problem on bash 3.x, because - In English bash man page, there was (and also is) no mention about how source behaves *in* posix mode for current path English bash man page explains how source behaves in *non*-posix mode only - And actually sh 3.x searched current path *in* posix mode But with bash 4.x, in posix mode sh no longer searches current path - This behavior is "correct" because English man page does not say anything how source behaves in posix mode for current path - But Japanese man page _does_ say that sh searches current path in posix mode. So now not only there is misinterpretation on Japanese man page, but also current Japanese man page says what is _against_ what sh in posix mode behaves.
(In reply to comment #8) > Do you want to say that during a startup when a breakage occures bash is in a > posix mode? I am not sure how but it appears that we are talking about two > different things. I understood the original report that something got mixed > up. I'm just saying that how this mistranslation bug impacts even though there are a workaround? I don't know when you were aware of you've got something mixed up though, if something is broken, it should be a bug in it and even if author of it was referring to this manpage during development, they shouldn't push their software without certain testing. basically manpage issues is highly unlikely to be set higher-priority, particularly with translated manpages. Anyway I'm trying to have a time to fix this though, won't happens soon maybe.
> - This behavior is "correct" because English man page does not > say anything how source behaves in posix mode for current path Is indeed bash in a posix mode during a startup? This is not clear to me and if not then errors in a service network are bash errors. That what I understood is the original report really about and that translation discrepancies really point to some mixups in an implementation. If I misread that then we are talking about different things. The other issue is that even if you are _allowed_ to change an undocumented behaviour is it really _wise_ to do so after so many years of bash in use. Is there some requirement which forces such move? Various destructive actions could be substituted in the argument above because nothing said before that something of that sort will not happen.
Better bring it up on fedora-devel-list if you are unsure, otherwise just file a bug to bash on bugzilla. discussing about it here won't make it clearer so that no persons in charge isn't in Cc at the moment. and bugzilla isn't a place to discuss IMHO.
Fixed in man-pages-ja-20090215-1.fc11.
(In reply to comment #13) > Fixed in man-pages-ja-20090215-1.fc11. (I met with different bug, but I will post here because I felt I don't want to open another ticket for the following reason...) # LANG=C yum -y upgrade man-pages-ja Loaded plugins: dellsysidplugin2 Setting up Upgrade Process Resolving Dependencies --> Running transaction check ---> Package man-pages-ja.noarch 0:20090215-1.fc11 set to be updated --> Finished Dependency Resolution Dependencies Resolved =============================================================== Package Arch Version Repository Size =============================================================== Updating: man-pages-ja noarch 20090215-1.fc11 koji-11 5.4 M Transaction Summary =============================================================== Install 0 Package(s) Update 1 Package(s) Remove 0 Package(s) Total size: 5.4 M Downloading Packages: Running rpm_check_debug Running Transaction Test Finished Transaction Test Transaction Check Error: file /usr/share/man/ja/man8/vigr.8.gz from install of man-pages-ja-20090215-1.fc11.noarch conflicts with file from package shadow-utils-2:4.1.2-11.fc11.i386
Hmm, well, this issue sometimes happens so I don't mind to remove it from the package though, the above logs looks strange to me. this manpage isn't actually new. you should be aware of it when you upgraded shadow-utils, no?
(In reply to comment #15) > Hmm, well, this issue sometimes happens so I don't mind to remove it from the > package though, the above logs looks strange to me. this manpage isn't actually > new. you should be aware of it when you upgraded shadow-utils, no? Oh, I didn't notice that this file is already owned by the two. Well, this happened because of the side-effect(?) of the change in redhat-rpm-config (i.e. rpm changed to use SHA-256 instead of MD5 for file digests). Currently latest shadow-utils rpm is using old MD5 checksum (and is under mass rebuild for this issue), newly compiled man-pages-ja already uses SHA-256. So even if these files are the same, on rpm database currently it is regarded as "different". Anyway removing one of this will resolve this issue and it will be no problem, I guess.
Aha. that makes sense. anyway, fixed in -2.fc11. Thank you for catching this up.
Seems good, thank you! Now closing as I reported for rawhide.