Puzzling over eval_gettext usage

[BarryK]

WoofQ builds a distro named EasyOS; however, I want to free it up, to build a distro with any name.
That means will have substitute "EasyOS" and "Easy" in gettext strings in scripts, with variables.
This requires using eval_gettext instead of gettext.

I found this old post:

https://oldforum.puppylinux.com/viewtopic.php?t=96326

Old forum member don570 recommends not to use

Code: Select all

. gettext.sh

as he says:

The bash manual says to do that but it just causes substitution problems.

Reading through that thread, I can't see why it causes problems.
It seems better than the other method using eval.

Anyone have experience with this?

[BarryK]

@don570
I didn't read that thread in the old forum as carefully as I could have.
Do you recall why ". gettext.sh" can cause trouble?

[step]

Bash provides two commands for sourcing a file, . (dot) and source. Dot is posix compatible.

.: . filename [arguments]
Execute commands from a file in the current shell.

Read and execute commands from FILENAME in the current shell. The
entries in $PATH are used to find the directory containing FILENAME.
If any ARGUMENTS are supplied, they become the positional parameters
when FILENAME is executed.

Exit Status:
Returns the status of the last command executed in FILENAME; fails if
FILENAME cannot be read.

So I guess two things could fail when running dot: PATH may not lead to the gettext.sh script; gettext.sh itself may fail. Neither of these is likely to happen in EasyOS or a properly configured Linux box. If you can't trust sourcing gettext.sh, you could grab the definitions of eval_gettext() and eval_ngettext() from it and stick them inside the script that needs them. I've done that in the past and it works, as long as the gettext package is installed, which provides command envsubst.

[Burunduk]

Drat! I found that using '. gettext.sh' would restrict my using curly brackets

${ var } for variable content . That was why I was avoiding it's use.[↑]

A simple test shows that indeed while a plain ${var} works, variables in a form ${var/a/b} or any other are not expanded.
Just a guess: maybe there was an eval_gettext script on don570's system and sourcing gettext.sh shadowed it.

[BarryK]

A simple test shows that indeed while a plain ${var} works, variables in a form ${var/a/b} or any other are not expanded.

Thanks for discovering that!

Then ". gettext.sh" will be ok for me, as I only want to replace occurrences of "EasyOS" in a string with a variable, so someone could use woofQ to build their own derivative, say "QuickOS" or whatever.

[step]

Just to clarify how eval_gettext 'my ${var}' and eval_gettext 'my $var' work because it can be confusing at first sight. Notice I wrapped the arguments of eval_gettext in single quotes? You must do the same. Double quotes are wrong and will lead to your string not being translated. In eval_gettext ${var} and $var aren't shell variables, they are the placeholders that eval_gettext looks for to do its magic (translating). So eval_gettext "my ${var}" (double quotes this time) is wrong because by the time the shell has expanded ${var} no placeholder is left for eval_gettext to do its magic anymore hence no translation. Of course, you will not notice this bug if you're running your script in the English locale but the bug is still there, ready to bite in another language.
The same applies to eval_gettext "my ${var/x/y}" and any shell parameter substitution: by the time the shell is done no placeholder is left for eval_gettext to do its magic. Using single quotes is also wrong in this case because ${var/x/y} isn't a valid gettext placeholder: only ${var} and $var are valid placeholders.

Note: above var stands for any valid identifier: a combination of letters, digits and underscores not starting with a digit.

[BarryK]

Can't you just use a back-slash with double-quotes?

Code: Select all

eval_gettext "something \${var}"

[step]

Sure you can because the shell will replace \$ with $ leaving ${var} to eval_gettext's consumption.
edit I also checked if xgettext correctly outputs ${var} as the message id in the .po translation file - it does.