6039 installgrub MBR update response check should use locale specific yesexpr

Review Request #69 — Created June 26, 2015 and submitted

tsoome
illumos-gate
6039
f3abc21...
general

6039 installgrub MBR update response check should use locale specific yesexpr

executed installgrub -m stage1 stage2 device and tested with different responses. only locale specific yes did result in mbr update. In et_EE the yesexpr is ^((jJ?)|(yY?))

root@test:/home/tsoome# ./installgrub -m /boot/grub/stage1 /boot/grub/stage2 /dev/rdsk/c3t2d0s0
Updating master boot sector destroys existing boot managers (if any).
continue (y/n)? kei
master boot sector not updated
Unable to gather device information for /dev/rdsk/c3t2d0s0
root@test:/home/tsoome# ./installgrub -m /boot/grub/stage1 /boot/grub/stage2 /dev/rdsk/c3t2d0s0
Updating master boot sector destroys existing boot managers (if any).
continue (y/n)? no
master boot sector not updated
Unable to gather device information for /dev/rdsk/c3t2d0s0
root@test:/home/tsoome# ./installgrub -m /boot/grub/stage1 /boot/grub/stage2 /dev/rdsk/c3t2d0s0
Updating master boot sector destroys existing boot managers (if any).
continue (y/n)? qui
master boot sector not updated
Unable to gather device information for /dev/rdsk/c3t2d0s0
root@test:/home/tsoome# ./installgrub -m /boot/grub/stage1 /boot/grub/stage2 /dev/rdsk/c3t2d0s0
Updating master boot sector destroys existing boot managers (if any).
continue (y/n)? jah
WARNING: target device /dev/rdsk/c3t2d0s0 has a versioned stage2 that is going to be overwritten by a non versioned one
stage2 written to partition 0, 289 sectors starting at 1024 (abs 1280)
stage1 written to partition 0 sector 0 (abs 256)
stage1 written to master boot sector
root@test:/home/tsoome# ./installgrub -m /boot/grub/stage1 /boot/grub/stage2 /dev/rdsk/c3t2d0s0
Updating master boot sector destroys existing boot managers (if any).
continue (y/n)? yes
stage2 written to partition 0, 289 sectors starting at 1024 (abs 1280)
stage1 written to partition 0 sector 0 (abs 256)
stage1 written to master boot sector
root@test:/home/tsoome# ./installgrub -m /boot/grub/stage1 /boot/grub/stage2 /dev/rdsk/c3t2d0s0
Updating master boot sector destroys existing boot managers (if any).
continue (y/n)? yes
stage2 written to partition 0, 289 sectors starting at 1024 (abs 1280)
stage1 written to partition 0 sector 0 (abs 256)
stage1 written to master boot sector
root@test:/home/tsoome# ./installgrub -m /boot/grub/stage1 /boot/grub/stage2 /dev/rdsk/c3t2d0s0
Updating master boot sector destroys existing boot managers (if any).
continue (y/n)? j
stage2 written to partition 0, 289 sectors starting at 1024 (abs 1280)
stage1 written to partition 0 sector 0 (abs 256)
stage1 written to master boot sector
root@test:/home/tsoome#

tsoome
tsoome
danmcd
  1. Seems okay to me. Please get one more review prior to RTI, however.

    1. I stand by this ship it, even with the removal of inc.flg.

  2. 
      
hans
  1. Ship It!
  2. 
      
risto3
  1. Sorry, let me understand something here... the question is answered in English, but the response is to be input localised?

    As I frequently work in multiple locales, I'd like to make sure that the question is always posed in the language
    that the response should be in (with apropriate yes/no clues like oui/non, kylää/ei, já/nei and so on)

    Example: how to differentiate between a greek Ναι/Όχι from a french Oui/Non

    (this is why I also don't like (y/n) which should be (yes/no))

    1. the question is formed in MBOOT_PROMPT macro, which is text wrapped into gettext(), so its the translators job to make sure yes/no is properly translated there - in english base text the y/n is fine, but nothing prevents translator to use form full word there to avoid potential confusion. from point of view of response check, both short and long cases are handled according to locale data (as seen in tests). also, afaik it is pretty much norm now to have locale specific yes/no expressions to include english variants as well, so despite the locale you can answer in english as well (not sure how universal this is, but seems so).

    2. LC_MESSAGES/LCL_DATA does seem to include english as you say, fine.
      Too bad existing programs don't force to locale "C" if the prompt text isn't translated.
      Perhaps the (y/n) should be (yes/no) by default...(see how it was done for rm() in cmd/rm/rm.c)

    3. IMO thats really bad style, you end up with partially translated message prompt. locale data is translated and rest of the message is not if there is no translation. Really ugly. Only feed full messages to gettext() and if needed, source message should be updated. I have done too much of the translation to go for such mixup;)

    4. btw, is this response satisfactory and can i proceed with RTI?:)

    5. NB I didn't open an issue, I asked for further information.

      I'll give an example (my locale is fr_FR.UTF-I):

      richard@omnis:/home/richard/tcom$ cp ../acpi.dmp  .
      richard@omnis:/home/richard/tcom$ compress -v acpi.dmp 
      acpi.dmp: Compression: 62,17% -- replaced with acpi.dmp.Z
      richard@omnis:/home/richard/tcom$ cp ../acpi.dmp  .
      richard@omnis:/home/richard/tcom$ compress -v acpi.dmp 
      acpi.dmp.Z already exists; do you wish to overwrite acpi.dmp.Z (oui or non)? n
          not overwritten
      richard@omnis:/home/richard/tcom$ rm -i acpi.dmp.Z 
      rm: remove acpi.dmp.Z (oui/non)? oui
      richard@omnis:/home/richard/tcom$ ls
      acpi.dmp
      

      I guess I'd rather let the advocates decide whether this derogation be allowed or not.

  2. 
      
tsoome
tsoome
Review request changed

Status: Closed (submitted)

Loading...