Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
Summary: description of "source" in bash in posix mode wrong
https://bugzilla.redhat.com/show_bug.cgi?id=481750
Summary: description of "source" in bash in posix mode wrong Product: Fedora Version: rawhide Platform: All OS/Version: Linux Status: NEW Severity: medium Priority: low Component: man-pages-ja AssignedTo: tagoh@redhat.com ReportedBy: mtasaka@ioa.s.u-tokyo.ac.jp QAContact: extras-qa@fedoraproject.org CC: tagoh@redhat.com, fedora-i18n-bugs@redhat.com Estimated Hours: 0.0 Classification: Fedora
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
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=481750
Michal Jaegermann michal@harddata.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |michal@harddata.com Severity|medium |high
--- Comment #1 from Michal Jaegermann michal@harddata.com 2009-01-27 21:52:54 EDT --- That tidbit is messing up seriously quite a chunk of a startup and surely a lots of stuff "out in the field".
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=481750
Akira TAGOH tagoh@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED Severity|high |low
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=481750
Jerry Amundson jamundso@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Priority|low |medium CC| |jamundso@gmail.com Severity|low |high
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=481750
Jerry Amundson jamundso@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Severity|high |low
--- Comment #2 from Jerry Amundson jamundso@gmail.com 2009-02-01 01:47:45 EDT --- (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" $
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=481750
--- Comment #3 from Jerry Amundson jamundso@gmail.com 2009-02-01 01:50:20 EDT --- (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.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=481750
--- Comment #4 from Mamoru Tasaka mtasaka@ioa.s.u-tokyo.ac.jp 2009-02-01 01:59:26 EDT --- (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 :)
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=481750
--- Comment #5 from Akira TAGOH tagoh@redhat.com 2009-02-01 20:42:51 EDT --- (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.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=481750
--- Comment #6 from Michal Jaegermann michal@harddata.com 2009-02-01 22:01:43 EDT ---
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.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=481750
--- Comment #7 from Akira TAGOH tagoh@redhat.com 2009-02-01 22:23:44 EDT --- (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.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=481750
--- Comment #8 from Michal Jaegermann michal@harddata.com 2009-02-02 02:26:07 EDT ---
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.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=481750
--- Comment #9 from Mamoru Tasaka mtasaka@ioa.s.u-tokyo.ac.jp 2009-02-02 02:54:28 EDT --- 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.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=481750
--- Comment #10 from Akira TAGOH tagoh@redhat.com 2009-02-02 03:02:02 EDT --- (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.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=481750
--- Comment #11 from Michal Jaegermann michal@harddata.com 2009-02-02 13:23:45 EDT ---
- 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.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=481750
--- Comment #12 from Akira TAGOH tagoh@redhat.com 2009-02-02 20:18:13 EDT --- 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.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=481750
Akira TAGOH tagoh@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |MODIFIED
--- Comment #13 from Akira TAGOH tagoh@redhat.com 2009-02-25 04:30:31 EDT --- Fixed in man-pages-ja-20090215-1.fc11.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=481750
--- Comment #14 from Mamoru Tasaka mtasaka@ioa.s.u-tokyo.ac.jp 2009-02-25 07:58:52 EDT --- (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
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=481750
--- Comment #15 from Akira TAGOH tagoh@redhat.com 2009-02-25 08:16:01 EDT --- 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?
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=481750
--- Comment #16 from Mamoru Tasaka mtasaka@ioa.s.u-tokyo.ac.jp 2009-02-25 08:26:24 EDT --- (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.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=481750
--- Comment #17 from Akira TAGOH tagoh@redhat.com 2009-02-25 08:31:14 EDT --- Aha. that makes sense. anyway, fixed in -2.fc11. Thank you for catching this up.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=481750
Mamoru Tasaka mtasaka@ioa.s.u-tokyo.ac.jp changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|MODIFIED |CLOSED Resolution| |RAWHIDE
--- Comment #18 from Mamoru Tasaka mtasaka@ioa.s.u-tokyo.ac.jp 2009-02-25 23:59:50 EDT --- Seems good, thank you! Now closing as I reported for rawhide.
i18n-bugs@lists.fedoraproject.org