On Sat, Apr 19, 2025 at 12:37:35PM +0200, Quentin Rameau wrote: > Now POSIX specifies: > > Affirmative Response > An input string that matches one of the responses acceptable to the > LC_MESSAGES category keyword *yesexpr*, matching an extended regular > expression in the current locale. > > LC_MESSAGES Category in the POSIX Locale > yesexpr "<circumflex><left-square-bracket><y><Y><right-square-bracket>" > "^[yY]" > noexpr "<circumflex><left-square-bracket><n><N><right-square-bracket>" > "^[nN]"
(For reference, here's the link:) https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/V1_chap07.html#tag_07_03_06_01 But yeah, if we want to follow this, then we can't do leading blank trimming... It does still allow discarding trailing chars, right? Since "yes" matches "^[yY]". (Also, does sbase deal with the whole locale mess?) > I would really like if we would flush stdin before prompting, > in order to avoid the other kind of issues This I'm fairly certain isn't allowed, we need to read a *single line* not "discard what's there and then read a line". Also, the line may not be coming from a tty either: https://pubs.opengroup.org/onlinepubs/9799919799/utilities/rm.html#tag_20_104_16 The -i option causes rm to prompt and read the standard input even if the standard input is not a terminal Practical example: `yes | some_script_with_hardcoded_rm_i` - NRK
