Re: better init.d/* : who carres ?
David Weinehall [EMAIL PROTECTED] writes: On Sat, Aug 27, 2005 at 02:16:39PM -0700, Thomas Bushnell BSG wrote: David Weinehall [EMAIL PROTECTED] writes: And while dash is also optional, all *correctly* written /bin/sh scripts should work with dash too. That's incorrect. A correctly written /bin/sh script is allowed to use Debian programs (including, say, test) and expect to get the Debian versions. Please read the thread on the policy list from quite a while ago. (Sorry for an extremely late reply, found this sorted into the wrong mailbox): test is in /usr/bin/ (together with [), thus at the very least init-scripts cannot rely on behaviour provided by /usr/bin/test, but make do with what /bin/sh provides, which limits you to what POSIX-test (e.g. dash) provides. I still believe you are incorrect. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: better init.d/* : who carres ?
On Sat, Aug 27, 2005 at 02:16:39PM -0700, Thomas Bushnell BSG wrote: David Weinehall [EMAIL PROTECTED] writes: And while dash is also optional, all *correctly* written /bin/sh scripts should work with dash too. That's incorrect. A correctly written /bin/sh script is allowed to use Debian programs (including, say, test) and expect to get the Debian versions. Please read the thread on the policy list from quite a while ago. (Sorry for an extremely late reply, found this sorted into the wrong mailbox): test is in /usr/bin/ (together with [), thus at the very least init-scripts cannot rely on behaviour provided by /usr/bin/test, but make do with what /bin/sh provides, which limits you to what POSIX-test (e.g. dash) provides. Regards: David Weinehall -- /) David Weinehall [EMAIL PROTECTED] /) Rime on my window (\ // ~ // Diamond-white roses of fire // \) http://www.acc.umu.se/~tao/(/ Beautiful hoar-frost (/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: better init.d/* : who carres ?
On Fri, 11 Nov 2005, David Weinehall wrote: On Sat, Aug 27, 2005 at 02:16:39PM -0700, Thomas Bushnell BSG wrote: David Weinehall [EMAIL PROTECTED] writes: And while dash is also optional, all *correctly* written /bin/sh scripts should work with dash too. That's incorrect. A correctly written /bin/sh script is allowed to use Debian programs (including, say, test) and expect to get the Debian versions. Please read the thread on the policy list from quite a while ago. (Sorry for an extremely late reply, found this sorted into the wrong mailbox): test is in /usr/bin/ (together with [), thus at the very least init-scripts cannot rely on behaviour provided by /usr/bin/test, but make do with what /bin/sh provides, which limits you to what POSIX-test (e.g. dash) provides. Er, only some such scripts; those that are run before /usr is available(which is a small set). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Re: Re: better init.d/* : who carres ?
Wed, 21 Sep 2005 09:32:41 +, Gerrit Pape wrote:
On Wed, Sep 21, 2005 at 05:07:31AM -0400, Alfie Costa wrote:
Russ Allbery [EMAIL PROTECTED] wrote:
I find constructs like ${string#*=} particularly difficult to read,
since they require that I remember what all the different punctuation
characters inside this sort of parameter expansion do. According to
the bash manual, there are sixteen of them, and I had to read the
description of ${parameter#word} three times before I completely
understood what it said.
1) The man page descriptions of these functions could probably be
improved.
There shouldn't be any problems with
$ man dash
/%word
OK, so maybe you'd concede the 'bash' version is knotty:
% man bash | grep -A 12 r%word
Reformatting bash(1), please wait...
${parameter%word}
${parameter%%word}
The word is expanded to produce a pattern just as in pathname
expansion. If the pattern matches a trailing portion of the
expanded value of parameter, then the result of the expansion is
the expanded value of parameter with the shortest matching pat-
tern (the ``%'' case) or the longest matching pattern (the
``%%'' case) deleted. If parameter is @ or *, the pattern
removal operation is applied to each positional parameter in
turn, and the expansion is the resultant list. If parameter is
an array variable subscripted with @ or *, the pattern removal
operation is applied to each member of the array in turn, and
the expansion is the resultant list.
Now 'dash':
% man dash | grep -A 4 r%word
Reformatting dash(1), please wait...
${parameter%word} Remove Smallest Suffix Pattern. The word is
expanded to produce a pattern. The parameter
expansion then results in parameter, with the
smallest portion of the suffix matched by the pat-
tern deleted.
...IS better, but it's like saying that McDonald's burgers are lower fat
than Wendy's. Both texts just seem to clog the reader's mental arteries.
Some may infer a distaste for the above texts as invincible ignorance --
and yet I understand what both are trying to say, and have programmed
with those useful constructs, (see previous attachment), and wish they
were used more. The trouble is that on receiving such tweaks for a slow
script, some weary maintainers complain code like that is Greek,
nobody uses it, it's hard to maintain, they don't want any.
It'd be nice to write an obvious improvement of the '${parameter%word}'
text. A few years back I attempted it, (not publicly), but the results
weren't satisfactory**. Which is not to suggest it can't be done, but
failing then was what inspired thoughts of sidestepping the difficulty
using wrapper functions with easy syntax and mnemonic names instead of
arbitrary chars like '#' and '%'.
(**A low-budget quandary: finding human guinea pigs to test read such
revisions. Preferably it should be somebody who doesn't know anything
about it -- if they can understand it, it's probably lucid.
Unfortunately such persons are usually so prejudiced against, or
intimidated by, tech text that they often blame themselves or try to
avoid it, saying oh it's fine, I'm too dumb to understand it,
especially if there's no immediate reward. Sadly, experts who are eager
to help are often bad test readers, they know too much; it's like asking
a weight lifter if some common object is heavy.)
More about the arbitrariness of '%' and '#' -- besides there being no
natural connection between a percent sign and a suffix, it's anyone's
guess why two percent signs '%%' should mean largest, and one sign '%'
should mean smallest. There are mnemonic tricks to help remember
arbitrary sets, like:
The Great Lakes / HOMES
Huron
Ontario
Michigan
Erie
Superior
...or, which is which:
stalagmite 'g' for ground
stalactite 'c' for ceiling
...but try come up with a rule of thumb for '%%' (big suffix), '#'
(small prefix), etc.? Maybe the 'p' in percent is for Prefix -- but no,
the Prefix is the hash symbol; two signs are bigger than one, like Roman
numerals... it's a puzzle.
That's why the wrapper functions.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: better init.d/* : who carres ?
Alfie Costa [EMAIL PROTECTED] writes: | Wed, 21 Sep 2005 09:32:41 +, Gerrit Pape wrote: | | ...but try come up with a rule of thumb for '%%' (big suffix), '#' | (small prefix), etc.? Maybe the 'p' in percent is for Prefix -- but no, | the Prefix is the hash symbol; two signs are bigger than one, like Roman | numerals... it's a puzzle. It's in fact easier; the keys can be visualized easily. On keyboard: # % is on the leftis on the right So, Delete left or Delete right. And the more character, there more deletion (That's %% and ##). Jari -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: better init.d/* : who carres ?
On Wed, 2005-09-28 at 23:56 +0300, Jari Aalto wrote: Alfie Costa [EMAIL PROTECTED] writes: | Wed, 21 Sep 2005 09:32:41 +, Gerrit Pape wrote: | | ...but try come up with a rule of thumb for '%%' (big suffix), '#' | (small prefix), etc.? Maybe the 'p' in percent is for Prefix -- but no, | the Prefix is the hash symbol; two signs are bigger than one, like Roman | numerals... it's a puzzle. It's in fact easier; the keys can be visualized easily. On keyboard: # % is on the leftis on the right Not on an en_GB keyboard they aren't. (Leaving aside the fact that at least en_GB iMac keyboards don't even have a key with a # legend). Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: better init.d/* : who carres ?
On 21-Sep-05, 03:41 (CDT), Eduard Bloch [EMAIL PROTECTED] wrote: Conclusion: usage of many (even simple) external programs is evil, though it may improve readability for some people. Replacing setting /bin/sh link to dash instead of bash and having more than 100 init scripts I can assume the whole boot would be 3s faster (1900Mhz box). Evil seems a strong term. There are other issues that sheer execution speed, and for init scripts, like most things, readability and maintainability (which are closely related) are far more important. A 3s gain in boot speed is pretty irrelevant, in the global scheme of things. Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: better init.d/* : who carres ?
On Fri, 23 Sep 2005, Steve Greenland wrote: Evil seems a strong term. There are other issues that sheer execution speed, and for init scripts, like most things, readability and Let's not forget that using stuff from /usr in an early initscript, or in one that could work without /usr (e.g. because the daemon is in /sbin) is a VERY BAD THING. maintainability (which are closely related) are far more important. A 3s gain in boot speed is pretty irrelevant, in the global scheme of things. Not on embedded systems, or in any stuff that needs to be instantly available (until we have fast-as-all-heck memory sw-suspend working properly, that is). -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: better init.d/* : who carres ?
On Thu, Aug 25, 2005 at 10:41:10AM +0200, Marc Chantreux wrote: zsh provides some things i've never seen in bash, for example : - file globbing flags, so you can set case insensitivity, That's a thing bash has: shopt -s nocaseglob. For the rest... -- Lionel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: better init.d/* : who carres ?
#include hallo.h * Henrique de Moraes Holschuh [Thu, Aug 25 2005, 12:17:56PM]: Well, as long as you don't start using stuff that breaks often, or that loads a ton of crap dynamically, or (even worse) is in /usr instead of /bin or /sbin... Note that using dash is probably MUCH faster than perl. I don't know about zsh. Well, I made some tests and can proof your claim. I have just tried a simple version of the skeleton script with /bin/true as the daemon, a simple config file to be read and optionaly a grep call in the script. The perl version was a straight-forward port of the script with internal grep method. Shell compatible config file reader was stolen from apt-cacher. Tests run with a loop like: time for x in `seq 1000` ; do perl skeleton.pl start ; perl skeleton.pl stop; done The results reflected my expectations, speed order: dash ... perl zsh bash; Perl is a lot faster than what some perl hatters try to make us believe. With external program calls, everything became really slow while usage of the internal Perl implementation demonstraged its advantage. perl ... dash ... zsh bash Conclusion: usage of many (even simple) external programs is evil, though it may improve readability for some people. Replacing setting /bin/sh link to dash instead of bash and having more than 100 init scripts I can assume the whole boot would be 3s faster (1900Mhz box). Personaly, I would write all init scripts in Perl but unfortunately compatibility considerations force us to do things that suck. Eduard. simple skeleton: dash: real0m6.538s user0m1.924s sys 0m3.880s bash: real0m30.406s user0m18.101s sys 0m8.197s perl: real0m15.195s user0m7.388s sys 0m7.324s zsh: real0m19.458s user0m8.773s sys 0m9.429s with external program (grep in the defaults file): dash: real0m23.050s user0m14.409s sys 0m6.664s perl: real0m18.820s user0m7.452s sys 0m7.560s bash: real0m46.683s user0m32.754s sys 0m13.105s more external programs (grep ... | cut ... | wc ...): dash: real0m40.917s user0m30.058s sys 0m10.089s bash: real1m2.397s user0m43.911s sys 0m16.525s Perl: (equivalent internal code) real0m15.604s user0m7.760s sys 0m7.444s -- youam nach duesseldorf zu freenet schaffe ich in einer verbindung auch ~5mb/s, ansonsten nur ziehend z.b. ftp.de.debian.org (dresden) ~4mb/s Zomb unglaublich... die Bandbreitensäue youam Zomb: hey, _du_ schickst doch für jeden einzelnen umlaut zwei byte über die leitung... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Re: better init.d/* : who carres ?
Russ Allbery [EMAIL PROTECTED] wrote:
I find constructs like ${string#*=} particularly difficult to read,
since they require that I remember what all the different punctuation
characters inside this sort of parameter expansion do. According to
the bash manual, there are sixteen of them, and I had to read the
description of ${parameter#word} three times before I completely
understood what it said.
Dunno if I can post on the list, (I'm not a devel), but have an opinion
anyhow, so...
Two views of the difficulty:
1) The man page descriptions of these functions could probably be
improved.
The trouble with obscure technical language is that when you complain,
it may inspire the snappy comeback that the complainer is too dumb to
understand the expert's smart terms**. Warfare ensues.
(**which every so often turns out to be true.)
Many maintainers are happy to fix text, especially if you send a patch.
The difficulty is that if you don't understand what you're trying to
rewrite because the original text is vague, (which could be all there is
to go on), then you can't be certain how to rewrite it. At that point
it helps to be able to ask the original author what they meant by
various words in their contexts. Which can be a tedious process,
because authors who write vague descriptions also may tend to give curt
or vague answers when asked, which can lead to several rounds of
questions to understand a single word. Mutual boredom or resentment may
ensue.
2) The syntax of those constructs IS cryptic, though they're useful
functions.
What follows describes a kludge for having one's cake and eating it, by
using little shell functions with easy syntax. A lot can be done with
POSIX.
See attached file (5K) for some shell functions mostly modeled after
BASIC functions, but could be made to match familiar string function
syntax in most any language. Examples:
% . ashstring.sh -lib # load functions in current shell
% x=Hello World
% len $x # length
11
% left $x 7 # left 7 chars
Hello W
% right $x 7 # right 7 chars
o World
% reverse $x
dlroW olleH
% splitchar `reverse $x`
d l r o W o l l e H
% mid $x 2 4 # middle 4 chars, starting from 2nd
ello
% instr $x Wor # what position is 'Wor'?
7
% ImGrep foo.* $x ; echo $? # is 'foo' in string?
1 # no
% ImGrep *llo* $x ; echo $? # is 'llo' in string?
0 # yes
# Note: 'ImGrep' isn't BASIC, but doesn't have proper regexps
# -- it works via 'case' expressions.
In a sense it's an additional library, which might be seen as excess
baggage, but the code itself is all just in-shell 'ash' (or 'dash')
functions -- low memory, often faster than using a util, with no pipes,
and no external binaries. I doubt the above functions have the best
possible syntax, (or behavior, not much error checking), but they're
easier to read than the shell code they're made up of; consider it a
proof of concept.
For 'init' scripts, it raises a question of which string operations are
the most common and useful. Some things are better done with external
utils like 'sed', but 'sed' or 'grep' may be overkill just to examine
one string.
Hope this is of interest...
ashstring.sh
Description: application/shellscript
Re: Re: better init.d/* : who carres ?
On Wed, Sep 21, 2005 at 05:07:31AM -0400, Alfie Costa wrote:
Russ Allbery [EMAIL PROTECTED] wrote:
I find constructs like ${string#*=} particularly difficult to read,
since they require that I remember what all the different punctuation
characters inside this sort of parameter expansion do. According to
the bash manual, there are sixteen of them, and I had to read the
description of ${parameter#word} three times before I completely
understood what it said.
1) The man page descriptions of these functions could probably be
improved.
There shouldn't be any problems with
$ man dash
/%word
Regards, Gerrit.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: better init.d/* : who carres ?
Henrique de Moraes Holschuh wrote: No. They are not even supposed to be scripts at all, it is pretty ok to use binary initscripts (but most people don't, and it really helps for stuff like that to be easy to debug, and binary is anything but). Ummm, not it's not. In particular, you'd be violating policy by 1) Placing binaries in /etc, in violation of FHS 3.4. 2) Policy 9.3.x, which says they're scripts multiple times 3) I strongly suspect you'd be violating Policy 10.7.3 on the behavior of configuration files. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: better init.d/* : who carres ?
[Henrique de Moraes Holschuh] No. They are not even supposed to be scripts at all, it is pretty ok to use binary initscripts [Anthony DeRobertis] Ummm, not it's not. And to make sure the scripts start in the correct order, the init.d scripts should include dependency information, for example in the LSB standard comment format described in URL: http://wiki.debian.net/?LSBInitScripts. If all init.d scripts used this format, it is simple to reorder the boot sequence according to this info, and to start scripts in parallel to speed up the boot process. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: better init.d/* : who carres ?
On Fri, Aug 26, 2005 at 10:19:06PM +0200, Adrian von Bidder wrote: On Wednesday 24 August 2005 17.15, Miquel van Smoorenburg wrote: Make sure you use only POSIX features when doing this. I think grep -o is a GNU extension, FreeBSD doesn't have it for example. Doesn't the 'only POSIX' apply to the shell code only? At least, shouldn't it be judged on a per-tool basis? While awk is (was?) usually mawk on Debian, and not gawk, I don't think anybody uses a BSD grep on their Debian system. Please don't standardise on a minimal future set only for the corner case that somebody cripples his system beyond every reassonable limit. The 'POSIX shell' rule is here for a reason: there are people with /bin/sh being not bash. For other tools, this rule can be relaxed, imho. Well, it's helpful when you might want to replace grep etc with its busybox counterparts; for instance, busybox grep doesn't support -o. Regards: David Weinehall -- /) David Weinehall [EMAIL PROTECTED] /) Rime on my window (\ // ~ // Diamond-white roses of fire // \) http://www.acc.umu.se/~tao/(/ Beautiful hoar-frost (/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: better init.d/* : who carres ?
David Weinehall [EMAIL PROTECTED] writes: And while dash is also optional, all *correctly* written /bin/sh scripts should work with dash too. That's incorrect. A correctly written /bin/sh script is allowed to use Debian programs (including, say, test) and expect to get the Debian versions. Please read the thread on the policy list from quite a while ago. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: better init.d/* : who carres ?
Henrique de Moraes Holschuh a écrit : Note that using dash is probably MUCH faster than perl. I don't know about zsh. it's not always true : it just depends on your problems and solutions : write a dash script to open a lot of pipes between grep,sed,awk and other filters to treat a lot of files or long ones will require more ressources than lauchning perl, compiling perlscript and running it faster than all those filters. for init scripts, we can suppose you're almost always true. regards mc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: better init.d/* : who carres ?
Henrique de Moraes Holschuh a écrit : Anyway, just make triple sure to never use anything from /usr in a script that otherwise only needs / to work. If you find anything like that, report it as a important (usually whatever it is starts after /usr is mounted) or grave (it starts befure /usr is mounted). yes! a can report some useless bashisms too ( the script can be dash compliant so). regards -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: better init.d/* : who carres ?
On Thu, Aug 25, 2005 at 12:17:56PM -0300, Henrique de Moraes Holschuh wrote: On Thu, 25 Aug 2005, Marc Chantreux wrote: that is a point which surprise me : i understand the dash for a posix and lightweight attitude but why use bash as modern shell ? why not perl or zsh (which are both more powerfull) ? Well, as long as you don't start using stuff that breaks often, or that loads a ton of crap dynamically, or (even worse) is in /usr instead of /bin or /sbin... Note that using dash is probably MUCH faster than perl. I don't know about zsh. Well, writing scripts that use /bin/sh or perl means that the init script will run without any dependencies on optional packages. zsh is Priority: optional... And while dash is also optional, all *correctly* written /bin/sh scripts should work with dash too. Regards: David Weinehall -- /) David Weinehall [EMAIL PROTECTED] /) Rime on my window (\ // ~ // Diamond-white roses of fire // \) http://www.acc.umu.se/~tao/(/ Beautiful hoar-frost (/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: better init.d/* : who carres ?
On Wednesday 24 August 2005 17.15, Miquel van Smoorenburg wrote: Make sure you use only POSIX features when doing this. I think grep -o is a GNU extension, FreeBSD doesn't have it for example. Doesn't the 'only POSIX' apply to the shell code only? At least, shouldn't it be judged on a per-tool basis? While awk is (was?) usually mawk on Debian, and not gawk, I don't think anybody uses a BSD grep on their Debian system. Please don't standardise on a minimal future set only for the corner case that somebody cripples his system beyond every reassonable limit. The 'POSIX shell' rule is here for a reason: there are people with /bin/sh being not bash. For other tools, this rule can be relaxed, imho. cheers -- vbi -- Ich kenne niemanden, der so oft Recht hat wie ich. -- Arno Schmidt pgpiwgHowvhar.pgp Description: PGP signature
Re: better init.d/* : who carres ?
First of all, thank you all for your answers.
i'll provide some documented, posix compliant, one piped patches as
wishlist.
Of course this would all be so much simpler if we could actually use the
power of modern shells (post 1993) in init scripts - subprocesses
wouldn't be required at all
that is a point which surprise me : i understand the dash for a posix
and lightweight attitude but why use bash as modern shell ? why not
perl or zsh (which are both more powerfull) ?
in zsh, for example, pipes are not required anymore for the
mysqld_get_param function :
# defaults are stored in an array
# global to the script because the result isn't volatile
local mysqld_defaults=( $(/usr/sbin/mysqld --print-defaults) )
mysqld_get_param () {
# ${mysqld_defaults%--$1*}
# returns all elements of mysqld_default that does not match
# --$1*
# (M) invert the result
#
# for all those elements, #*= delete the '=' caracter and
# every symbols before it.
echo ${${(M)mysqld_defaults%--$1*}#*=}
}
regards
mc
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: better init.d/* : who carres ?
On Thu, 2005-08-25 at 09:35 +0200, Marc Chantreux wrote:
that is a point which surprise me : i understand the dash for a posix
and lightweight attitude but why use bash as modern shell ? why not
perl or zsh (which are both more powerfull) ?
bash is actually pretty good if you know how to use it (and most of the
ksh93 comliant functions) - the problem is that most programmers don't.
The ${} constructs add a lot of power and allow the programmer to be
less reliant on external tools.
in zsh, for example, pipes are not required anymore for the
mysqld_get_param function :
Your example is little different to a good ksh/bash implementation
(though pipes aren't a bad thing so shouldn't necessarily be shyed away
from).
signature.asc
Description: This is a digitally signed message part
Re: better init.d/* : who carres ?
Andrew Porter a écrit :
bash is actually pretty good if you know how to use it (and most of the
ksh93 comliant functions) - the problem is that most programmers don't.
The ${} constructs add a lot of power and allow the programmer to be
less reliant on external tools.
zsh provides some things i've never seen in bash, for example :
- alternative syntax for complete commands, so you can write
for f (*gz) gzip -d $f
- file globbing flags, so you can set case insensitivity, sort by file
size ...
- a lot of good things like = generation to search in $PATH
at least, i think zsh is better because it's almost 200k thinner:
% ls -sh =zsh4 =bash
616K /bin/bash 456K /bin/zsh4
Your example is little different to a good ksh/bash implementation
(though pipes aren't a bad thing so shouldn't necessarily be shyed away
from).
sure! but it's faster without them.
regards
mc
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: better init.d/* : who carres ?
On Thu, 2005-08-25 at 10:41 +0200, Marc Chantreux wrote: at least, i think zsh is better because it's almost 200k thinner: % ls -sh =zsh4 =bash 616K /bin/bash 456K /bin/zsh4 I acutally use ksh for all my shell scripts (bash hasn't quite made it yet IMHO) and that beats both - 636K /bin/ksh But for my uses I care little for the odd kilobyte saved in a program thats being used in so many instances. I also use php for a lot of scripting using the command line php interpreter. signature.asc Description: This is a digitally signed message part
Re: better init.d/* : who carres ?
to, 2005-08-25 kello 09:35 +0200, Marc Chantreux kirjoitti: that is a point which surprise me : i understand the dash for a posix and lightweight attitude but why use bash as modern shell ? why not perl or zsh (which are both more powerfull) ? I think it would be good for us to take pity on the sysadmins and avoid forcing them to learn a multitude of scripting languages just to be able to understand init.d scripts. At least when I do sysadmin work, I often have to at least peek at the init.d scripts; for some reason, this happens much less often with package maintainer scripts. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: better init.d/* : who carres ?
On Wed, 24 Aug 2005, Marc Chantreux wrote: that are not bugs so i wonder if package maintainers where pleased if i reportbug those lines as wishlist. Why would they be displeased? Anyway, just make triple sure to never use anything from /usr in a script that otherwise only needs / to work. If you find anything like that, report it as a important (usually whatever it is starts after /usr is mounted) or grave (it starts befure /usr is mounted). -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: better init.d/* : who carres ?
On Wed, 24 Aug 2005, Peter Palfrader wrote:
mysqld_get_param () {
/usr/sbin/mysqld --print-defaults |
sed -ne s/^.*--$1=\\([^ ]\\+\\).*\$/\\1/p
}
And harder to read. Making scripts more complex and harder to read for
Huh? Anyone that has problem with that sed expression really has no
business touching initscripts IMHO.
Whether it is worth it or not speed-wise, is something else. But the less
external dependencies you have in initscripts, the better IMHO.
--
One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie. -- The Silicon Valley Tarot
Henrique Holschuh
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: better init.d/* : who carres ?
On Wed, 24 Aug 2005, Andrew Porter wrote: Both require knowledge of a particular tools - one only one tool though. Once you have that knowledge I would suggest that the single command version is easier to read (though I personally would use awk). awk is in /usr, and I recall I got problems with at least one initscript that I wanted to work without /usr (and it ONLY referred to stuff in /bin and /sbin otherwise, including the service proper) because of awk. Also, in pursuit of faster boot times, the single process solution is more keen. Yes. Of course this would all be so much simpler if we could actually use the power of modern shells (post 1993) in init scripts - subprocesses wouldn't be required at all Is there a reason why we cannot do so in Debian? IMHO we should strive to have initscripts use everything available in ash (as long as it is also in bash) that could help them run better. And drop posh as the irrelevance it really is. This would not hold true for upstream initscripts, or for third-party ones, but Debian is a controlled environment on that regard. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: better init.d/* : who carres ?
On Wed, 24 Aug 2005, Mauro Calderara wrote: Aren't the init-scripts supposed to be posix-compilant? Often when No. They are not even supposed to be scripts at all, it is pretty ok to use binary initscripts (but most people don't, and it really helps for stuff like that to be easy to debug, and binary is anything but). installing dash as /bin/sh this becomes a problem because even though dash is posix-compatible it tends to break init-scripts for me. Whether Those are bugs, and grave ones at that. Report them. If it doesn't run with dash, it must not #! /bin/sh. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: better init.d/* : who carres ?
On Thu, 25 Aug 2005, Marc Chantreux wrote: that is a point which surprise me : i understand the dash for a posix and lightweight attitude but why use bash as modern shell ? why not perl or zsh (which are both more powerfull) ? Well, as long as you don't start using stuff that breaks often, or that loads a ton of crap dynamically, or (even worse) is in /usr instead of /bin or /sbin... Note that using dash is probably MUCH faster than perl. I don't know about zsh. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: better init.d/* : who carres ?
On Thu, Aug 25, 2005 at 12:09:32PM -0300, Henrique de Moraes Holschuh wrote:
mysqld_get_param () {
/usr/sbin/mysqld --print-defaults |
sed -ne s/^.*--$1=\\([^ ]\\+\\).*\$/\\1/p
}
And harder to read. Making scripts more complex and harder to read for
Huh? Anyone that has problem with that sed expression really has no
business touching initscripts IMHO.
...
I've been using sed since 1997, IIRC. I still don't grok that expression
fluently. Are you saying that people who don't read the (IMHO rather arcane)
sed regex syntax, having problems with such syntax, shouldn't touch
initscripts? At the very least, it should commented that what is does is
indeed converting (whatever) --foo=bar (whatever) to bar when $1=foo.
/* Steinar */
--
Homepage: http://www.sesse.net/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: better init.d/* : who carres ?
On Thu, 25 Aug 2005, Steinar H. Gunderson wrote: fluently. Are you saying that people who don't read the (IMHO rather arcane) sed regex syntax, having problems with such syntax, shouldn't touch I am saying that people who *can't* read the sed regex syntax, shouldn't touch Debian initscripts, yes. Note that can't and don't are different. If you don't, and you need to, you do some reading and learn it at least for enough time to fix whatever you need to fix. If you can't, stay away from initscripts. initscripts? At the very least, it should commented that what is does is indeed converting (whatever) --foo=bar (whatever) to bar when $1=foo. Now, commenting it would be a good thing, yes. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: better init.d/* : who carres ?
On Thu, Aug 25, 2005 at 12:44:13PM -0300, Henrique de Moraes Holschuh wrote: On Thu, 25 Aug 2005, Steinar H. Gunderson wrote: fluently. Are you saying that people who don't read the (IMHO rather arcane) sed regex syntax, having problems with such syntax, shouldn't touch I am saying that people who *can't* read the sed regex syntax, shouldn't touch Debian initscripts, yes. i would consider knowledge of sed and regex's very valuable and desirable to have, but not exclusive of the ability to maintain init scripts. in fact, the vast majority of init scripts do not even use sed (i can't quantitatively say this for regexes though). sean -- signature.asc Description: Digital signature
Re: better init.d/* : who carres ?
On Thu, 25 Aug 2005, sean finney wrote: On Thu, Aug 25, 2005 at 12:44:13PM -0300, Henrique de Moraes Holschuh wrote: On Thu, 25 Aug 2005, Steinar H. Gunderson wrote: fluently. Are you saying that people who don't read the (IMHO rather arcane) sed regex syntax, having problems with such syntax, shouldn't touch I am saying that people who *can't* read the sed regex syntax, shouldn't touch Debian initscripts, yes. i would consider knowledge of sed and regex's very valuable and desirable to have, but not exclusive of the ability to maintain init See the difference between can't and don't in the parent post. The mindset that implies in can't really, really doesn't belong anywhere critical system infrastructure. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
better init.d/* : who carres ?
Hi all,
there are a lot of things in /etc/init.d/*, and {pre,post}inst
scripts that can be rewritten more efficiently ( i think ).
for example, in /etc/init.d/mysqld
mysqld_get_param() {
/usr/sbin/mysqld --print-defaults \
| tr \n \
| grep -- --$1 \
| tail -n 1 \
| cut -d= -f2
}
can be written like :
mysqld_get_param () {
local string=$( /usr/sbin/mysqld --print-defaults | grep -o -- --$1=[^ ]*
)
echo ${string#*=}
}
that are not bugs so i wonder if package maintainers where pleased if i
reportbug those lines as wishlist.
can you advice me?
regards
mc
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: better init.d/* : who carres ?
On Wed, Aug 24, 2005 at 04:50:40PM +0200, Marc Chantreux wrote: that are not bugs so i wonder if package maintainers where pleased if i reportbug those lines as wishlist. Why not? a patch is a patch. -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: better init.d/* : who carres ?
that are not bugs so i wonder if package maintainers where pleased if i reportbug those lines as wishlist. If you submit patch as wishlist, then it's ok (at least for me). O. -- Ondrej Sury [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: better init.d/* : who carres ?
In article [EMAIL PROTECTED],
Marc Chantreux [EMAIL PROTECTED] wrote:
there are a lot of things in /etc/init.d/*, and {pre,post}inst
scripts that can be rewritten more efficiently ( i think ).
for example, in /etc/init.d/mysqld
mysqld_get_param() {
/usr/sbin/mysqld --print-defaults \
| tr \n \
| grep -- --$1 \
| tail -n 1 \
| cut -d= -f2
}
can be written like :
mysqld_get_param () {
local string=$( /usr/sbin/mysqld --print-defaults | grep -o --
--$1=[^ ]* )
echo ${string#*=}
}
that are not bugs so i wonder if package maintainers where pleased if i
reportbug those lines as wishlist.
Make sure you use only POSIX features when doing this. I think
grep -o is a GNU extension, FreeBSD doesn't have it for example.
So in this case, the solution below is better (and shorter):
mysqld_get_param () {
/usr/sbin/mysqld --print-defaults |
sed -ne s/^.*--$1=\\([^ ]\\+\\).*\$/\\1/p
}
Mike.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: better init.d/* : who carres ?
On Wed, 24 Aug 2005, Miquel van Smoorenburg wrote:
for example, in /etc/init.d/mysqld
mysqld_get_param() {
/usr/sbin/mysqld --print-defaults \
| tr \n \
| grep -- --$1 \
| tail -n 1 \
| cut -d= -f2
}
can be written like :
mysqld_get_param () {
local string=$( /usr/sbin/mysqld --print-defaults | grep -o --
--$1=[^ ]* )
echo ${string#*=}
}
So in this case, the solution below is better (and shorter):
mysqld_get_param () {
/usr/sbin/mysqld --print-defaults |
sed -ne s/^.*--$1=\\([^ ]\\+\\).*\$/\\1/p
}
And harder to read. Making scripts more complex and harder to read for
some dubious efficiency is not a good idea in my opinion.
--
PGP signed and encrypted | .''`. ** Debian GNU/Linux **
messages preferred.| : :' : The universal
| `. `' Operating System
http://www.palfrader.org/ | `-http://www.debian.org/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: better init.d/* : who carres ?
On Wed, 2005-08-24 at 17:44 +0200, Peter Palfrader wrote: I could debate with you whether /usr/sbin/mysqld --print-defaults \ | tr \n \ | grep -- --$1 \ | tail -n 1 \ | cut -d= -f2 is harder to read than /usr/sbin/mysqld --print-defaults | sed -ne s/^.*--$1=\\([^ ]\\+\\).*\$/\\1/p Both require knowledge of a particular tools - one only one tool though. Once you have that knowledge I would suggest that the single command version is easier to read (though I personally would use awk). Also, in pursuit of faster boot times, the single process solution is more keen. Of course this would all be so much simpler if we could actually use the power of modern shells (post 1993) in init scripts - subprocesses wouldn't be required at all signature.asc Description: This is a digitally signed message part
Re: better init.d/* : who carres ?
hi,
On Wed, Aug 24, 2005 at 04:50:40PM +0200, Marc Chantreux wrote:
for example, in /etc/init.d/mysqld
mysqld_get_param() {
/usr/sbin/mysqld --print-defaults \
| tr \n \
| grep -- --$1 \
| tail -n 1 \
| cut -d= -f2
}
can be written like :
mysqld_get_param () {
local string=$( /usr/sbin/mysqld --print-defaults | grep -o -- --$1=[^
]* )
echo ${string#*=}
}
as a general rule, stuff like this can be reported as wishlist bugs
to the package in question (with patch attached). i think in many cases
if what you are doing is replacing a set of hackish/semi-broken commands
with something simpler and more elegant, you'll have a good chance of
having the patch accepted.
in this case, however, you are reducing a set of simple and non-intensive
system commands from 5 to 3 (and possibly introducing some non-posixish
stuff according to Miquel). i can't guarantee you christian or i would
bother to include it. reduce it to one fairly understandable command and
maybe :)
sean
signature.asc
Description: Digital signature
Re: better init.d/* : who carres ?
On Wed, Aug 24, 2005 at 05:22:32PM +0100, Andrew Porter wrote: /usr/sbin/mysqld --print-defaults \ | tr \n \ | grep -- --$1 \ | tail -n 1 \ | cut -d= -f2 is harder to read than /usr/sbin/mysqld --print-defaults | sed -ne s/^.*--$1=\\([^ ]\\+\\).*\$/\\1/p Both require knowledge of a particular tools - one only one tool though. that's not completely true, unless knowledge of sed also implies a good understanding of posix regular expressions, in which case i wouldn't be so hasty to claim it was easier to understand. however, all of this notwithstanding, if someone takes the time to submit a patch similar to this it will probably be included. Of course this would all be so much simpler if we could actually use the power of modern shells (post 1993) in init scripts - subprocesses wouldn't be required at all it is a /bin/bash script, so i suppose bashisms are allowed, provided that there aren't other reasons christian or i would object to them. sean -- signature.asc Description: Digital signature
Re: better init.d/* : who carres ?
** Peter Palfrader ::
mysqld_get_param () {
/usr/sbin/mysqld --print-defaults |
sed -ne s/^.*--$1=\\([^ ]\\+\\).*\$/\\1/p
}
And harder to read. Making scripts more complex and harder to
read for some dubious efficiency is not a good idea in my opinion.
I respectfully disagree, especially in the example case, in the
following counts:
1. In the example case, we have four pipes (five concurrent
processes), and here we have only one, which I think settles the
performance gain in the non-dubious zone.
2. In the example case, one regexp in the sed command-line explains
quite clearly what you want to extract from the output of
print-defaults, which I think settles the case for the making
scripts more complex and harder to read. I was still in doubt of
what the script extracted from the output of print-defaults until I
saw the regexp.
If I was the DD in charge, I would apply the patch.
--
HTH,
Massa
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: better init.d/* : who carres ?
Marc Chantreux [EMAIL PROTECTED] writes:
there are a lot of things in /etc/init.d/*, and {pre,post}inst scripts
that can be rewritten more efficiently ( i think ).
for example, in /etc/init.d/mysqld
mysqld_get_param() {
/usr/sbin/mysqld --print-defaults \
| tr \n \
| grep -- --$1 \
| tail -n 1 \
| cut -d= -f2
}
can be written like :
mysqld_get_param () {
local string=$( /usr/sbin/mysqld --print-defaults | grep -o -- --$1=[^
]* )
echo ${string#*=}
}
that are not bugs so i wonder if package maintainers where pleased if i
reportbug those lines as wishlist.
It would certainly be fine for me to get wishlist bugs of this sort
against my packages, although in this particular case I would probably
close the bug with the explanation that I find the first form easier to
read and don't think the efficiency difference is particularly important.
I find constructs like ${string#*=} particularly difficult to read, since
they require that I remember what all the different punctuation characters
inside this sort of parameter expansion do. According to the bash manual,
there are sixteen of them, and I had to read the description of
${parameter#word} three times before I completely understood what it said.
The advantage of the original form is that each one of those lines is
doing something very simple and straightforward. Yes, you have to
understand the function of four different programs, but each of those four
programs are considerably simpler than sed or awk and the ways in which
they're being used are very common ones.
--
Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: better init.d/* : who carres ?
On Wed, Aug 24, 2005 at 11:08:41PM +0200, Mauro Calderara wrote: Aren't the init-scripts supposed to be posix-compilant? Often when installing dash as /bin/sh this becomes a problem because even though dash is posix-compatible it tends to break init-scripts for me. Whether this is dash's fault or the init-scripts is beyond my knowledge since I don't know POSIX very well. But still I think bashisms should be avoided. /bin/sh init scripts are supposed to be posix sh compliant (with an additional specification about echo in policy). but as i said, it is a *bash* script... sean -- signature.asc Description: Digital signature
Re: better init.d/* : who carres ?
On Aug 24, 2005, at 11:19 PM, sean finney wrote: On Wed, Aug 24, 2005 at 11:08:41PM +0200, Mauro Calderara wrote: Aren't the init-scripts supposed to be posix-compilant? Often when installing dash as /bin/sh this becomes a problem because even though dash is posix-compatible it tends to break init-scripts for me. Whether this is dash's fault or the init-scripts is beyond my knowledge since I don't know POSIX very well. But still I think bashisms should be avoided. /bin/sh init scripts are supposed to be posix sh compliant (with an additional specification about echo in policy). but as i said, it is a *bash* script... #!/bin/bash # # MySQL daemon start/stop script. Right you are ... I'm sorry, should have checked before posting. You have my apologies sean mauro -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: better init.d/* : who carres ?
On Aug 24, 2005, at 6:43 PM, sean finney wrote: On Wed, Aug 24, 2005 at 05:22:32PM +0100, Andrew Porter wrote: /usr/sbin/mysqld --print-defaults \ | tr \n \ | grep -- --$1 \ | tail -n 1 \ | cut -d= -f2 is harder to read than /usr/sbin/mysqld --print-defaults | sed -ne s/^.*--$1=\\([^ ]\\+\\).*\$/\\1/p Both require knowledge of a particular tools - one only one tool though. that's not completely true, unless knowledge of sed also implies a good understanding of posix regular expressions, in which case i wouldn't be so hasty to claim it was easier to understand. however, all of this notwithstanding, if someone takes the time to submit a patch similar to this it will probably be included. Of course this would all be so much simpler if we could actually use the power of modern shells (post 1993) in init scripts - subprocesses wouldn't be required at all it is a /bin/bash script, so i suppose bashisms are allowed, provided that there aren't other reasons christian or i would object to them. Aren't the init-scripts supposed to be posix-compilant? Often when installing dash as /bin/sh this becomes a problem because even though dash is posix-compatible it tends to break init-scripts for me. Whether this is dash's fault or the init-scripts is beyond my knowledge since I don't know POSIX very well. But still I think bashisms should be avoided. sean mauro -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
