I am looking at some Gentoo startup scripts. I notice that when a variable
name is referenced, it is surrounded by squiggly brackets (braces). I tried
some test code without the brackets, and it appeared to function ok. I was
wondering what purpose the brackets serve.

Thanks in advance,

Mark.

--
Mark Hobley
393 Quinton Road West
QUINTON
Birmingham
B32 1QE

Email: markhobley at hotpop dot donottypethisbit com

http://markhobley.yi.org/

Mark Hobley wrote:

> I am looking at some Gentoo startup scripts. I notice that when a variable
> name is referenced, it is surrounded by squiggly brackets (braces). I tried
> some test code without the brackets, and it appeared to function ok. I was
> wondering what purpose the brackets serve.

Try

a="some text"
echo "${a}more text"

If you omit the braces here, the shell thinks the variable name is
${amore}.

But most of the time these braces are just cosmetic (so it's easier to
read, perhaps).

The runscript syntax is just the Bash syntax (/sbin/runscript runs
bash), so you can get more info in "info bash" and any bash tutorial you
can find on the net.

Regards...
Michael

Michael Mauch <michael.mauch@gmx.de> wrote:
> Mark Hobley wrote:
>
>> I am looking at some Gentoo startup scripts. I notice that when a
>> variable name is referenced, it is surrounded by squiggly brackets
>> (braces). I tried some test code without the brackets, and it
>> appeared to function ok. I was wondering what purpose the brackets
>> serve.
>
> Try
>
> a="some text"
> echo "${a}more text"
>
> If you omit the braces here, the shell thinks the variable name is
> ${amore}.
>
> But most of the time these braces are just cosmetic (so it's easier to
> read, perhaps).

They also are needed if you want to do things like this:

user = ${USER:-nobody}

Which will set $user to whatever $USER is set to, or "nobody" if USER wasn't
set.

In some cases they are also needed to avoid shell expansions or to avoid
confusion with arguments to your shell ($1, $2 et cetera).
But mostly, they protect against the variable name changing if placed next
to other text, and thus protects against cut/paste errors. At the price of
two bytes. Unless a script is timing critical and removing the {}'s would
allow it to become a disk block shorter[1], I'd leave them. :-)

[1]: Or even better, stored directly in the inode for file systems that
support this for VERY short files. There are some very rare cases where
I've stripped comments, whitespace and unneccessary {} pairs to make scripts
shorter -- either because they were timing critical on a production system,
or because I needed to cram more of them into the limited space of a floppy.

Regards,
--
*Art

In alt.os.linux.gentoo Michael Mauch <michael.mauch@gmx.de> wrote:

> The runscript syntax is just the Bash syntax (/sbin/runscript runs
> bash), so you can get more info in "info bash" and any bash tutorial you
> can find on the net.

Ok thanks for that. Unfortunately there was no man page for runscript, and I
am not that familiar with bash, so I didn't recognize the syntaxes.

Out of interest, what does runscript provide that bash does not? Why do the
scripts use /sbin/runscript instead of /bin/bash?

Mark.

--
Mark Hobley
393 Quinton Road West
QUINTON
Birmingham
B32 1QE

Email: markhobley at hotpop dot donottypethisbit com

http://markhobley.yi.org/

Mark Hobley wrote:
> In alt.os.linux.gentoo Michael Mauch <michael.mauch@gmx.de> wrote:
>
>> The runscript syntax is just the Bash syntax (/sbin/runscript runs
>> bash), so you can get more info in "info bash" and any bash tutorial you
>> can find on the net.
>
> Ok thanks for that. Unfortunately there was no man page for runscript, and I
> am not that familiar with bash, so I didn't recognize the syntaxes.
>
> Out of interest, what does runscript provide that bash does not? Why do the
> scripts use /sbin/runscript instead of /bin/bash?

If you start one of the init files with the "#! /sbin/runscript", it
displays a bit of help.

If you use "strings /sbin/runscript", you can see something about
selinux, /etc/conf.d/env_whitelist, /lib/rcscripts/sh/rc-help.sh and
/sbin/runscript.sh. So the /sbin/runscript does really a bit more than
the plain bash. And it has a lot of builtin functions (like ebegin and
eend). But for starters it's good to know that it's not another special
syntax, but bash, because bash is used underneath the hood.

There's also some documentation for the init scripts in
<http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=2&chap=4#doc_chap4>

Regards...
Michael

Michael Mauch <michael.mauch@gmx.de> wrote:

> If you use "strings /sbin/runscript", you can see something about
> selinux, /etc/conf.d/env_whitelist, /lib/rcscripts/sh/rc-help.sh and
> /sbin/runscript.sh. So the /sbin/runscript does really a bit more than
> the plain bash. And it has a lot of builtin functions (like ebegin and
> eend).

Ok, I could really do with a detailed MAN page on this. (Especially the
internal functions stuff)

> But for starters it's good to know that it's not another special
> syntax, but bash, because bash is used underneath the hood.

What difference would #!/bin/bash make of #!/sbin/runscript? Presumably the
"internal functions" would be treated as empty (null) or failed functions.

Are the internal functions actually called from the scripts somewhere?

> There's also some documentation for the init scripts in
> <http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=2&chap=4#doc_chap4>

Yeah, I've seen that. I want some very detailed specifics about the startup
sequences though, so I have started to reverse-engineer the startup scripts and
document the startup process.

I have also developed a very crude fix, using a modprobe command. I would like
to tidy this up to perform appropriate kernel checks and load the module
using the appropriate scripted functions. (It is just lack of experience
slowing me down here.)

http://markhobley.yi.org:9098/InstFixUDS

Mark.

--
Mark Hobley
393 Quinton Road West
QUINTON
Birmingham
B32 1QE

Email: markhobley at hotpop dot donottypethisbit com

http://markhobley.yi.org/