Shell Programming and Scripting

hi,

i am new to unix shell scripting,i have a sed expression that says

sed -e 's/ \([a-zA-Z0-9]*/)\(.T[A-Z]*Game\)/Player\2/g'


can someone tell me how this works and the possible inputs it takes

your sed expression doesn't work. here is the corrected one. btw, this might not be a good solution to do the substitution. e.g.
(.T[A-Z]*Game\) what happens, if after "T", there is another "T"? anyway, here is the info you want:

Code:

echo " abcd1024xTBLAHBLAHGame"|sed -n 's/ \([a-zA-Z0-9]*\)\(.T[A-Z]*Game\)/Player\2/g;p'
PlayerxTBLAHBLAHGame

may i know how the change u made is resulting in the ouput and y is mine not working?

your statement:

Code:

sed -e 's/ \([a-zA-Z0-9]*/)\(.T[A-Z]*Game\)/Player\2/g'

it should be

Code:

\(

, or it won't work.

If this sed implementation honors locales and if the locale is set to one of the English utf8 locales, the highlighted range expression will be more promiscuous than intended. The reason why is that these utf8 locales interleave the alphabet so that the collation order specified by A-Z also includes all but one of the lowercase letters.

The [a-zA-Z] construct, under those utf8 locales, will cover the entire English alphabet but will include all but 2 letters twice. Fortunately, this still gives the same result as when each letter is included only once.

If the desired match is the uppercase alphabet in the current locale's language (whatever that may be), then the [:upper:] character class should be used.

If only the uppercase English alphabet is to be matched, the script can use [:upper:] with any of the English language locales or it can use [:upper:] or [A-Z] with the C/POSIX locale. In either case, if English only is to be matched, the script should explicitly specify the locale to protect itself against future changes in its invoking environment's locale.

All range expressions (even [0-9]) are technically undefined outside of the POSIX locale. Do not use them unless the C/POSIX locale is in effect. This may seem like a pointless nit, but a few times over the past couple of years I've diagnosed range expressions outside of the C/POSIX locale as the cause of failure in scripts that had worked fine for over a decade. Take my word for it and be kind to your future self, for this bug manifests itself intermittently and, to someone not familiar with how the locale affects the collating sequence, in an unfathomable way.

Regards,
Alister

@alister



valuable comment!