Bug 481750 - description of "source" in bash in posix mode wrong
description of "source" in bash in posix mode wrong
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: man-pages-ja (Show other bugs)
rawhide
All Linux
medium Severity low
: ---
: ---
Assigned To: Akira TAGOH
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-01-27 08:43 EST by Mamoru TASAKA
Modified: 2009-02-25 23:59 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-02-25 23:59:50 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Mamoru TASAKA 2009-01-27 08:43:24 EST
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
Comment 1 Michal Jaegermann 2009-01-27 21:52:54 EST
That tidbit is messing up seriously quite a chunk of a startup and surely a lots of stuff "out in the field".
Comment 2 Jerry Amundson 2009-02-01 01:47:45 EST
(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"
$
Comment 3 Jerry Amundson 2009-02-01 01:50:20 EST
(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.
Comment 4 Mamoru TASAKA 2009-02-01 01:59:26 EST
(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 :)
Comment 5 Akira TAGOH 2009-02-01 20:42:51 EST
(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.
Comment 6 Michal Jaegermann 2009-02-01 22:01:43 EST
> 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.
Comment 7 Akira TAGOH 2009-02-01 22:23:44 EST
(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.
Comment 8 Michal Jaegermann 2009-02-02 02:26:07 EST
> 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.
Comment 9 Mamoru TASAKA 2009-02-02 02:54:28 EST
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.
Comment 10 Akira TAGOH 2009-02-02 03:02:02 EST
(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.
Comment 11 Michal Jaegermann 2009-02-02 13:23:45 EST
>   - 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.
Comment 12 Akira TAGOH 2009-02-02 20:18:13 EST
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.
Comment 13 Akira TAGOH 2009-02-25 04:30:31 EST
Fixed in man-pages-ja-20090215-1.fc11.
Comment 14 Mamoru TASAKA 2009-02-25 07:58:52 EST
(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
Comment 15 Akira TAGOH 2009-02-25 08:16:01 EST
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?
Comment 16 Mamoru TASAKA 2009-02-25 08:26:24 EST
(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.
Comment 17 Akira TAGOH 2009-02-25 08:31:14 EST
Aha. that makes sense. anyway, fixed in -2.fc11. Thank you for catching this up.
Comment 18 Mamoru TASAKA 2009-02-25 23:59:50 EST
Seems good, thank you!
Now closing as I reported for rawhide.

Note You need to log in before you can comment on or make changes to this bug.