Re: New personal experimental book [warning: lots of UTF-8 in this]
Colin Watson wrote: On Tue, Sep 30, 2008 at 09:03:00PM -0500, DJ Lucas wrote: Other packages in the base LFS utilize BDB. They may or may not work with GDBM so I'll be looking into that as soon as we get updated to reasonable revisions of all installed 'base' software. My question, however, will man-db-2.5.3 allow continued used of BDB in the near future? Yes (--with-db=db, or --with-db=dbN for N=1-4), although I can't promise to test it very often. We use the notorious Debian-patched groff 1.18.1.1 and configure man-db with --enable-mb-groff. I'd rather that not be the only possible alternative, of course. My real concern is the version of groff being used. I did not see mention of a current groff version which was *my* original concern. I want to use what works, but I also want to stay as close to upstream as possible for all packages because we (LFS) do not have the development staff that distributions have. Keep in mind that LFS is an educational product, not a 'distribution', though many use it as their 'distribution' of choice. Utilizing Debian's work in this area was great (and will continue to be I think). It allowed Alexander to provide a working setup for almost all cases, and explain in detail the future issues (though the current text, like much of the book ATM, is now out of date). For staying as close to groff upstream as possible, you probably want to use the preconv preprocessor included in CVS groff. That eliminates the need for the Debian multibyte patch for most languages. Unfortunately there has been no new upstream release of groff since that work was done. The remaining problem is that nobody's yet finished the work on character classes in groff, which mean that certain kinds of specialised typography don't work: in particular the line-breaking algorithm required for Japanese text (kinsoku shori) isn't implemented. This is the reason we're still sticking with the multibyte patch in Debian for now, since I want to avoid introducing regressions. I think everything other than CJK should work with preconv, although feedback from people actually regularly using it wouldn't hurt. Thanks for the detailed response Colin. For the immediate future, LFS will have to stick with your known working method. Maybe later we can look into backports of groff-cvs. -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: New personal experimental book [warning: lots of UTF-8 in this]
CC'ing to lfs-dev, if I've remembered to change to a subscribed address. On Tue, Sep 30, 2008 at 04:54:33PM +0100, Colin Watson wrote: On Tue, Sep 30, 2008 at 03:48:50PM +0100, Ken Moffat wrote: On Tue, Sep 30, 2008 at 12:27:09PM +0100, Colin Watson wrote: I've been looking into the adoption of man-db in various distributions lately, and ran into your post archived at http://linuxfromscratch.org/pipermail/lfs-dev/2008-September/061632.html. I'm not subscribed to lfs-dev so can't easily reply directly there, but I wanted to reply to one point as I thought it was a bit odd: Long-term, UTF-8 is the only sensible solution for text encoding, in the same way that a terminal on an X desktop is the only way to read some languages. In my view, packages such as man-db are prolonging the pain of the transition by encouraging people to use legacy encodings. But, for me as an English speaker the pain is minimal. Others may conclude that the pain of conversion to UTF-8 should be deferred. Modern versions of man-db default to expecting UTF-8 for manual page source (although if they realise that the page is actually encoded in a legacy encoding then they'll automatically fall back to that), and will generate whatever is appropriate for the user's locale. I like the sound of that. It's not the way we've been doing things since we switched to man-db in LFS, and we have text (perhaps carried forward in error) saying that man-db can't display UTF-8. See http://www.linuxfromscratch.org/lfs/view/development/chapter06/man-db.html part 6.45.2 in the middle of the page. Ah, that definitely used to be true but is false as of man-db 2.5.0 (though you should really use at least 2.5.1 - 2.5.0 didn't get the encoding fallback logic quite right). Since I have the opportunity (and thanks, I hadn't seen that page before), it seems worth going through the rest of that page. If I should file these as bugs instead, let me know, or feel free to forward this to lfs-dev, or whatever. I suppose one of _us_ ought to file it, once this hits the list archives. The first change is a sed substitution to delete the “/usr/man” and “/usr/local/man” lines in the man_db.conf file to prevent redundant results when using programs such as whatis: Do you make /usr/man and /usr/local/man symlinks? If so, I could detect that and skip them automatically. The second change accounts for programs that Man-DB should be able to find at runtime, but that haven't been installed yet: I made configure options available for these in 2.5.0, so you could use '--with-browser=lynx --with-col=col --with-vgrind=vgrind --with-grap=grap' instead. Prepare Man-DB for compilation: I think I already suggested this to somebody else at LFS, but I'd recommend that you use --with-db=gdbm rather than the default of Berkeley DB (which is something of an awkward beast, and overkill for man-db). This will be the default in man-db 2.5.3. And, yes, I think you can get rid of the convert-mans business entirely. With the exception of a few hopelessly misencoded pages that are really lost causes, man-db can pretty much cope with any of the obvious candidates for encoding pages in each language now. I noticed a comment in there about Norwegian not working, and have fixed it for man-db 2.5.3. In the distributions I'm most directly involved with, namely Debian and Ubuntu, everything is set up for UTF-8 output by default, and we've arranged for the packaging tools to automatically convert pages to UTF-8 on installation with the aid of some helper tools I ship with man-db; while this latter item has only been running for a few months, it won't be long until we'll be running with UTF-8 across the board. As soon as groff upstream finishes off Unicode support then we'll use that and the whole pipeline will be UTF-8, but for the meantime we recode back and forward behind the scenes and very few people have to notice or care. I'll also take a look at this part, it sounds good. I hope you're not holding your breath for a UTF-8-capable version of groff ;-) Oh, certainly not; I've put a lot of effort into not holding my breath for that! That said, I'd be entirely happy to make man-db able to use groff-utf8 as an option if that's what you guys would prefer. I haven't yet looked at what you are doing in 2.5.2, or what versions of groff you are using in ubuntu and debian, but I'm fairly sure most LFS users won't want to use groff-utf8 if it isn't needed. It's only a temporary hack until groff is fixed. Is there some misunderstanding here about what man-db is doing? If so, I'd be happy to explain. Thanks for the offer, I might take you up on it in a few weeks. NB my estimates for how long things will take me are always way out, so that might be next year! Depends on how long I spend beating my head
Re: New personal experimental book [warning: lots of UTF-8 in this]
Ken Moffat wrote: On Tue, Sep 30, 2008 at 04:54:33PM +0100, Colin Watson wrote: On Tue, Sep 30, 2008 at 03:48:50PM +0100, Ken Moffat wrote: On Tue, Sep 30, 2008 at 12:27:09PM +0100, Colin Watson wrote: Modern versions of man-db default to expecting UTF-8 for manual page source (although if they realise that the page is actually encoded in a legacy encoding then they'll automatically fall back to that), and will generate whatever is appropriate for the user's locale. I like the sound of that. It's not the way we've been doing things since we switched to man-db in LFS, and we have text (perhaps carried forward in error) saying that man-db can't display UTF-8. See http://www.linuxfromscratch.org/lfs/view/development/chapter06/man-db.html part 6.45.2 in the middle of the page. Ah, that definitely used to be true but is false as of man-db 2.5.0 (though you should really use at least 2.5.1 - 2.5.0 didn't get the encoding fallback logic quite right). Since I have the opportunity (and thanks, I hadn't seen that page before), it seems worth going through the rest of that page. If I should file these as bugs instead, let me know, or feel free to forward this to lfs-dev, or whatever. I suppose one of _us_ ought to file it, once this hits the list archives. This CC to lfs-dev is sufficient, but if you or anyone else wants to correct the text, please file away. :-) The first change is a sed substitution to delete the “/usr/man” and “/usr/local/man” lines in the man_db.conf file to prevent redundant results when using programs such as whatis: Do you make /usr/man and /usr/local/man symlinks? If so, I could detect that and skip them automatically. The second change accounts for programs that Man-DB should be able to find at runtime, but that haven't been installed yet: I made configure options available for these in 2.5.0, so you could use '--with-browser=lynx --with-col=col --with-vgrind=vgrind --with-grap=grap' instead. Prepare Man-DB for compilation: I think I already suggested this to somebody else at LFS, but I'd recommend that you use --with-db=gdbm rather than the default of Berkeley DB (which is something of an awkward beast, and overkill for man-db). This will be the default in man-db 2.5.3. Other packages in the base LFS utilize BDB. They may or may not work with GDBM so I'll be looking into that as soon as we get updated to reasonable revisions of all installed 'base' software. My question, however, will man-db-2.5.3 allow continued used of BDB in the near future? And, yes, I think you can get rid of the convert-mans business entirely. With the exception of a few hopelessly misencoded pages that are really lost causes, man-db can pretty much cope with any of the obvious candidates for encoding pages in each language now. This is very nice! I noticed a comment in there about Norwegian not working, and have fixed it for man-db 2.5.3. In the distributions I'm most directly involved with, namely Debian and Ubuntu, everything is set up for UTF-8 output by default, and we've arranged for the packaging tools to automatically convert pages to UTF-8 on installation with the aid of some helper tools I ship with man-db; These will also be very useful in BLFS. while this latter item has only been running for a few months, it won't be long until we'll be running with UTF-8 across the board. As soon as groff upstream finishes off Unicode support then we'll use that and the whole pipeline will be UTF-8, but for the meantime we recode back and forward behind the scenes and very few people have to notice or care. I'll also take a look at this part, it sounds good. I hope you're not holding your breath for a UTF-8-capable version of groff ;-) Oh, certainly not; I've put a lot of effort into not holding my breath for that! That said, I'd be entirely happy to make man-db able to use groff-utf8 as an option if that's what you guys would prefer. I haven't yet looked at what you are doing in 2.5.2, or what versions of groff you are using in ubuntu and debian, but I'm fairly sure most LFS users won't want to use groff-utf8 if it isn't needed. It's only a temporary hack until groff is fixed. Definitely not. It looks like a sensible, long-term solution will be here soon. If man-db is already doing the leg work for the interim solution, then we have a much larger development team (Debian) to follow for guidance. We'd be much better off without the wrapper for groff. Is there some misunderstanding here about what man-db is doing? If so, I'd be happy to explain. Thanks for the offer, I might take you up on it in a few weeks. NB my estimates for how long things will take me are always way out, so that might be next year! Depends on how long I spend beating my head against the various versions of mozilla on ppc64, plus
Re: New personal experimental book [warning: lots of UTF-8 in this]
Στις Sunday 14 September 2008 22:00:58 ο/η Ken Moffat έγραψε: On Sun, Sep 14, 2008 at 11:20:04PM +0600, Alexander E. Patrakov wrote: On Sunday 14 September 2008 21:47:05 Ken Moffat wrote: Ken, if the LFS server again blacklists gmail, please forward this to the list again I had the same problem some time ago, but it was due to the fact that I was sending mails from a different address than the one I was registered to the list. lefteris -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: New personal experimental book [warning: lots of UTF-8 in this]
Ken Moffat wrote: On Sun, Sep 14, 2008 at 07:03:03AM -0600, Alexander E. Patrakov wrote: snip OK. I assume that adding | iconv -f UTF-8 -t //TRANSLIT to the end will make the line work also in non-UTF-8 locales (manual pages are still expected to be in UTF-8). Could you please test this? You suggested that, or something very like it, to me before. On that occasion I didn't manage to make it work. snip The following locales provide an English error message: hu_HU.UTF-8, id_ID.UTF-8, ja_JP.UTF-8, ko_KR.UTF-8, nb_NO.UTF-8, nn_NO.UTF-8, sv_SE.UTF-8, tr_TR.UTF-8, vi_VN.UTF-8, zh_CN.UTF-8. preceded by spam about NLSPATH? No, not on my modified clfs yesterday, nor on the LFS-6.3 I'm using today. So... This is doable for the locales that man supports only, all others get English error messages and no NLSPATH spam? Pages totally in utf8 _might_ also work on non utf8 consoles with Alexander's suggestion above (or something like it)? It doesn't fix the out of date pages problem, but it's a step forward from man just a few months ago. Am I following correctly so far? -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: New personal experimental book [warning: lots of UTF-8 in this]
On Sun, Sep 14, 2008 at 07:03:03AM -0600, Alexander E. Patrakov wrote:
On Saturday 13 September 2008 21:31:48 Ken Moffat wrote:
resending privately, because LFS recognized this as spam, feel free
to forward
OK, I'll try to CC it.
On Sat, Sep 13, 2008 at 05:12:00PM +0600, Alexander E. Patrakov
wrote:
Let's clarify the situation a bit. There are three possible
outcomes for
man foo in the ru_RU.UTF-8 locale:
1) Glibberish (unacceptable, but, unfortunately, what happens if
the
system is misconfigured by an English-speaking editor who doesn't
know
how to test the configuration)
2) No such manual page (well, OK if it indeed doesn't exist)
3) English manpage (acceptable, although not ideal)
4) Russian manpage.
From the box I'm using today (clfs amd pure64 from a few months
ago,
with your ncursesw change, man-1.6e (straight configure without
specifying any lang value), groff-utf8
OK. However, due to some doubts expressed below, I would like to see
the complete buildscript.
[EMAIL PROTECTED] ~ $LC_ALL=ru_RU.UTF-8 man foo
Ничего про foo в руководстве нет
Indeed, the message is correct. However, this is in urxvt, which is
known to print some characters, not invalid character marks, when
passed invalid UTF-8. I suspect this is what happened here, and the
characters somehow became correct. Unless you reencoded the
translation files yourself (as RedHat does), there is simply no code
in Man that can lead to correct characters.
Well spotted, Sir! I'd forgotten that in my clfs builds I do
indeed recode the messages and pages. So much for my memory, and my
apologies for spreading confusion or lies. The guilty part of the
script is now attached, I guess my point now becomes if even I can
do it, any fool can get an all-UTF-8 system. Sorry.
That probably also explains why some quick testing in a tty on this
system (LFS-6.3) failed totally to provide anything other than
English messages of 'No manual entry for foo'.
Could you please retest in any VTE-based terminal (sakura from
http://www.pleyades.net/david/sakura.php is very lightweight, as well
as termit from http://code.google.com/p/termit/wiki/TermIt ) or in
uxterm? While your results already look well-done and convincing, I
think that it would be even better to post screenshots showing the
output of locale, yes --help and man foo in one terminal window.
I'll maybe get around to trying other terms in a few days. No
promises, I'm afraid. Not quite sure if I've yet picked up
everything you want to establish - the earlier tests were just run
with 'LC_ALL=xx.YY-UTF-8 man foo' ?
After installing groff-utf8 I make the following change to man.conf
to actually use it:
sed -i /^NROFF/s'/nroff -Tlatin1/groff-utf8 -Tutf8/' /etc/man.conf
OK. I assume that adding | iconv -f UTF-8 -t //TRANSLIT to the end
will make the line work also in non-UTF-8 locales (manual pages are
still expected to be in UTF-8). Could you please test this?
You suggested that, or something very like it, to me before. On
that occasion I didn't manage to make it work.
Long-term, UTF-8 is the only sensible solution for text encoding,
Long-term, due to pollution on Earth, Mars is the only sensible
destination for the mankind :) - i.e. please don't use long term
arguments as a motivation to do something right now.
snip man pages that seem to be rendered correctly
The following locales provide an English error message:
hu_HU.UTF-8, id_ID.UTF-8, ja_JP.UTF-8, ko_KR.UTF-8, nb_NO.UTF-8,
nn_NO.UTF-8, sv_SE.UTF-8, tr_TR.UTF-8, vi_VN.UTF-8, zh_CN.UTF-8.
preceded by spam about NLSPATH?
No, not on my modified clfs yesterday, nor on the LFS-6.3 I'm using
today.
--
Alexander E. Patrakov
ĸen
--
das eine Mal als Tragödie, das andere Mal als Farce
echo converting bg
iconv -t utf-8 -f cp1251 -o msgs/mess.bg.utf msgs/mess.bg 2$LOG
mv -v msgs/mess.bg.utf msgs/mess.bg 2$LOG
echo converting ja
iconv -t utf-8 -f euc-jp -o msgs/mess.ja.utf msgs/mess.ja 2$LOG
mv -v msgs/mess.ja.utf msgs/mess.ja 2$LOG
echo converting ko
iconv -t utf-8 -f euc-kr -o msgs/mess.ko.utf msgs/mess.ko 2$LOG
mv -v msgs/mess.ko.utf msgs/mess.ko 2$LOG
echo converting ru
iconv -t utf-8 -f koi8-r -o msgs/mess.ru.utf msgs/mess.ru 2$LOG
mv -v msgs/mess.ru.utf msgs/mess.ru 2$LOG
for M in msgs/mess.{da,de,es,fi,fr,it,nl,pt}; do
echo converting $M to utf-8
echo converting $M to utf-8 $LOG
iconv -t utf-8 -f iso-8859-1 -o ${M}.utf ${M} 2$LOG
mv -v ${M}.utf ${M} $LOG 21
done
for M in msgs/mess.{cs,hr,pl,ro,sl}; do
echo converting $M to utf-8
echo converting $M to utf-8 $LOG
iconv -t utf-8 -f iso-8859-2 -o ${M}.utf ${M} 2$LOG
mv -v ${M}.utf ${M} $LOG 21
done
echo converting el
iconv -t utf-8 -f iso-8859-7 -o msgs/mess.el.utf msgs/mess.el 2$LOG
mv -v msgs/mess.el.utf msgs/mess.el 2$LOG
# looks as if zh_TW.UTF-8 messages will be found,
# and
Re: New personal experimental book [warning: lots of UTF-8 in this]
On Sun, Sep 14, 2008 at 11:20:04PM +0600, Alexander E. Patrakov wrote: On Sunday 14 September 2008 21:47:05 Ken Moffat wrote: Ken, if the LFS server again blacklists gmail, please forward this to the list again OK. My own filters noted the following, which I think is normal for gmail. Anyone able to comment on this ? X-Spam-Status: No, score=2.3 required=3.5 tests=BAYES_00,DNS_FROM_RFC_POST, FORGED_RCVD_HELO,RCVD_IN_SORBS_WEB,SPF_PASS,URIBL_SBL Well spotted, Sir! I'd forgotten that in my clfs builds I do indeed recode the messages and pages. So much for my memory, and my apologies for spreading confusion or lies. The guilty part of the script is now attached, I guess my point now becomes if even I can do it, any fool can get an all-UTF-8 system. Sorry. Well, my point is that, by converting man messages you created a system that cannot be converted to non-UTF-8 locale (i.e., repeated the mistake of RedHat 8). Could you please retest in any VTE-based terminal (sakura from http://www.pleyades.net/david/sakura.php is very lightweight, as well as termit from http://code.google.com/p/termit/wiki/TermIt ) or in uxterm? While your results already look well-done and convincing, I think that it would be even better to post screenshots showing the output of locale, yes --help and man foo in one terminal window. I'll maybe get around to trying other terms in a few days. No promises, I'm afraid. Not quite sure if I've yet picked up everything you want to establish - the earlier tests were just run with 'LC_ALL=xx.YY-UTF-8 man foo' ? I cancel this request, as we found the reason of your results. Although, I'd like to see why you don't get this (or, what you get instead of this): === [EMAIL PROTECTED] ~]$ LANG=nn_NO.UTF-8 man foo Cannot open the message catalog man for locale nn_NO.UTF-8 (NLSPATH=none) No manual entry for foo === preceded by spam about NLSPATH? No, not on my modified clfs yesterday, nor on the LFS-6.3 I'm using today. Strange. I'll look further into this tomorrow. -- Alexander E. Patrakov -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: New personal experimental book [warning: lots of UTF-8 in this]
On Sat, Sep 13, 2008 at 05:12:00PM +0600, Alexander E. Patrakov wrote: Let's clarify the situation a bit. There are three possible outcomes for man foo in the ru_RU.UTF-8 locale: 1) Glibberish (unacceptable, but, unfortunately, what happens if the system is misconfigured by an English-speaking editor who doesn't know how to test the configuration) 2) No such manual page (well, OK if it indeed doesn't exist) 3) English manpage (acceptable, although not ideal) 4) Russian manpage. From the box I'm using today (clfs amd pure64 from a few months ago, with your ncursesw change, man-1.6e (straight configure without specifying any lang value), groff-utf8 [EMAIL PROTECTED] ~ $LC_ALL=ru_RU.UTF-8 man foo Ничего про foo в руководстве нет [EMAIL PROTECTED] ~ $ I can't read it, but it looks plausibly translated. For pages that exist in russian on my system, see examples below. After installing groff-utf8 I make the following change to man.conf to actually use it: sed -i /^NROFF/s'/nroff -Tlatin1/groff-utf8 -Tutf8/' /etc/man.conf This system for my use is intended to support _only_ UTF-8 locales, and I don't have any pressing need to convert any other text (sometimes I get mail where e.g. '£' (pound sign) is replaced, but I can live with that). People who have to use files in other encodings will need to find solutions which work for them. The following examples are intended to show what appears to work - they are pasted from urxvt. I can't read the ideograms, but they look plausible. For console users, all the alphabetic versions (latin alphabets, cyrillic alphabets, greek) are expected to work e.g. with my sigma-consolefonts font if you have nothing better. Sorry about the long lines in a few of these. Long-term, UTF-8 is the only sensible solution for text encoding, in the same way that a terminal on an X desktop is the only way to read some languages. In my view, packages such as man-db are prolonging the pain of the transition by encouraging people to use legacy encodings. But, for me as an English speaker the pain is minimal. Others may conclude that the pain of conversion to UTF-8 should be deferred. 1. Versions of apropos.1 from man bg_BG.UTF-8 ИМЕ apropos - търсене на низ в базата от данни на whatis cs_CZ.UTF-8 JMÉNO apropos - hledej řetězec v databázi whatis da_DK.UTF-8 NAVN apropos - gennemsøg 'whatis' databasen for tekststrenge de_DE.UTF-8 NAME apropos - durchsucht die whatis Datenbank nach Zeichenketten el_GR.UTF-8 ONOMA apropos - ερευνά τη βάση δεδομένων whatis για συμβολοσειρές es_ES.UTF-8 NOMBRE apropos - busca `cadenas' en la base de datos whatis fi_FI.UTF-8 NIMI apropos - etsi whatis-tietokannasta merkkijonoja fr_FR.UTF-8 NOM apropos - recherche de chaînes de caractères dans la base de données whatis hr_HR.UTF-8 IME apropos - traži niz u whatis bazi podataka it_IT.UTF-8 NOME apropos - ricerca stringhe nel database di whatis ja_JP.UTF-8 名前 apropos - whatis データベースより文字列を検索する。 ko_KR.UTF-8 NAME apropos - whatis 데이타베이스의 문자열을 검색한다 nl_NL.UTF-8 NAAM apropos - zoek een gegeven string in de whatis database pl_PL.UTF-8 NAZWA apropos - wyszukuje łańcuchy znaków w bazie whatis pt_PT.UTF8 NOME apropos - procura `strings' na base de dados whatis ro_RO.UTF-8 NUME apropos - caută şiruri de caractere în baza de date whatis sl_SI.UTF-8 IME apropos - poišči ključno besedo v datoteki whatis 2. Various pages from shadow-4.1.0 before debian took it over. Some of these are only minimally translated. cs_CZ.UTF-8 vipw (8) JMÉNO vipw, vigr - slouží k úpravě souborů password, group, shadow-password a shadow- group. de_DE.UTF-8 vipw (8) NAME vipw, vigr - bearbeitet die Passwort-, Gruppen-, Shadow-Passwort- oder Shadow- Gruppen-Datei es_ES.UTF-8 vipw (8) NOMBRE vipw, vigr — editan los ficheros de cuentas y grupos fi_FI.UTF-8 passwd (1) NIMI passwd - päivitä käyttäjän todennustunnukset fr_FR.UTF-8 vipw (8) NOM vipw, vigr - éditer les fichiers passwd, group, shadow ou gshadow hu_HU.UTF-8 passwd (5) NÉV passwd - Jelszófájl id_ID.UTF-8 useradd (8) NAME useradd - Membuat user baru atau memperbarui informasi tentang user baru it_IT.UTF-8 vipw (8) NOME vipw, vigr - edit the password, group, shadow-password or shadow-group file (only a few of the headings have been translated) ja_JP.UTF-8 8 vipw (8) 名前 vipw, vigr - password, group とそれぞれの shadow ファイルを編集する ko_KR.UTF-8 vipw (8) NAME vipw — 패스워드 파일 편집 pl_PL.UTF-8 vipw (8) NAZWA vipw, vigr - edytuj plik haseł, grup lub ich wersji chronionych pt_BR.UTF-8 passwd (5) NOME passwd - arquivo de senhas ru_RU.UTF-8 vipw (8) НАЗВАНИЕ vipw, vigr - служат для редактирования файлов паролей, групп, теневых паролей пользователей или групп. sv_SE.UTF-8 vipw (8) NAMN vipw, vigr - redigera lösenordet,
