On Sat, 2010-10-23 at 15:20 +0400, Anthony Pankov wrote:
> Greetings.
>
> Just for note.
>
> Some time ago i thought about the same problem.
> I started something then had delayed it forever in favour of fast wrong
> way.
>
> So, the aim was:
>
> ---
> NAME
> modcfg - modify configuration
>
>
On Sat, Oct 09, 2010 at 03:39:44PM -0700, Devin Teske wrote:
> On Oct 9, 2010, at 1:25 PM, Garrett Cooper wrote:
[...]
> The second usage (": function") aids in finding the function
> declaration among the usages. See, in Perl, I can simply search for
> "sub" preceding the function name. In C, I te
On 10/07/2010 05:19 AM, Douglas K. Rand wrote:
I think that this script might also fill a void with using Puppet as a
configuration tool. Currently Puppet, as its default behaviour, uses
files in /etc/rc.conf.d to set variables.
This is no longer the case. Current versions edit /etc/rc.conf.
-
On 10/8/2010 7:12 AM, Daniel Gerzo wrote:
On 7.10.2010 15:42, Warren Block wrote:
Consider also the docs that tell the user to
echo 'something_enable="YES"' >> /etc/rc.conf
which can produce duplicate and possibly differing entries. Or
non-working entries if there was no ending \n present, or e
On Oct 10, 2010, at 5:15 PM, Garrett Cooper wrote:
> On Sun, Oct 10, 2010 at 3:49 PM, Devin Teske wrote:
>
>> Hmmm, sysctl(9) is lock-free, which might imply that both sysctl(8) and
>> sysctl(3) are also lock-free, and proposed sysrc(8) is lock-free, so might
>> that imply that the atomicity te
Devin Teske writes:
>>> GLOBALS
>>>
>>> # Global exit status variables
>>> : ${SUCCESS:=0}
>>> : ${FAILURE:=1}
>>
>> Should this really be set to something other than 0 or 1 by the
>> end-user's environment? This would simplify a lot
On 10/10/10 8:46 PM, Devin Teske wrote:
On Oct 10, 2010, at 4:51 PM, Garance A Drosihn mailto:dro...@rpi.edu>> wrote:
The latter does not cause an error. Try it:
# [ "-n" = x ] ; echo $?
1
# [ -e = "no" ] ; echo $?
1
# [ -e = -n ] ; echo $?
1
1 is error. 0 is success.
--
Um, yes, true.
On 10/10/10 7:09 PM, Devin Teske wrote:
On Oct 9, 2010, at 10:25 PM, Julian Elischer wrote:
For what it matters, I'v enever found the [ "x$foo" = "x" ] construct to be
useful.
the quoting seems to work for everything I've ever worked on.
There have been times where I had scripts wh
On Oct 10, 2010, at 4:51 PM, Garance A Drosihn wrote:
> The latter does not cause an error. Try it:
>
> # [ "-n" = x ] ; echo $?
> 1
>
> # [ -e = "no" ] ; echo $?
> 1
>
> # [ -e = -n ] ; echo $?
> 1
1 is error. 0 is success.
--
Devin
___
freebsd-ha
On Oct 10, 2010, at 4:51 PM, Garance A Drosihn wrote:
> On 10/10/10 7:09 PM, Devin Teske wrote:
>> However, enclosing the argument (as the 'x$foo' portion is really just the
>> first argument to the '[' built-in) in quotes:
>>
>> [ "$foo" = x ]
>>
>> makes it so that the expansion is taken as
On Sun, Oct 10, 2010 at 3:49 PM, Devin Teske wrote:
> Trimming further context...
> On Oct 9, 2010, at 7:30 PM, Garrett Cooper wrote:
...
> Perhaps you meant env FAILURE=0 sysrc foo && reboot ?
>
> $ cat failure.sh
> #!/bin/sh
> echo "FAILURE: $FAILURE"
> $ FAILURE=0 && sh failure.sh
> FAILURE:
On Oct 9, 2010, at 10:25 PM, Julian Elischer wrote:
> Ah grasshoppers...
>
> /me wonders if anyone will get the full significance of that..
>
>
> On 10/9/10 3:39 PM, Devin Teske wrote:
>> On Oct 9, 2010, at 1:25 PM, Garrett Cooper wrote:
>>
>>
>>> Why not just do...
>>>
>>> if [ "x$rc_conf_
Trimming further context...
On Oct 9, 2010, at 7:30 PM, Garrett Cooper wrote:
> Trimming out some context...
>
> On Sat, Oct 9, 2010 at 3:39 PM, Devin Teske wrote:
>>
>
> ...
>
> Perhaps you meant env FAILURE=0 sysrc foo && reboot ?
>
> $ cat failure.sh
> #!/bin/sh
> echo "FAILURE: $FAILURE
> On 10/9/10 7:30 PM, Garrett Cooper wrote:
> >
> >> [ "..." ] is the same thing as [ -n "..." ] or test -n "..."
> >> [ ! "..." ] is the same things as [ -z "..." ] or test -z "..."
> >> I'll never understand why people have to throw an extra letter in there and
> >> then compare it to that lett
On 10/9/10 7:30 PM, Garrett Cooper wrote:
[ "..." ] is the same thing as [ -n "..." ] or test -n "..."
[ ! "..." ] is the same things as [ -z "..." ] or test -z "..."
I'll never understand why people have to throw an extra letter in there and
then compare it to that letter.
I ran into issues
Ah grasshoppers...
/me wonders if anyone will get the full significance of that..
On 10/9/10 3:39 PM, Devin Teske wrote:
On Oct 9, 2010, at 1:25 PM, Garrett Cooper wrote:
Why not just do...
if [ "x$rc_conf_files" = x -o "x$varname" = x ]
then
return ${FAILURE-1}
fi
I think you'll fin
Trimming out some context...
On Sat, Oct 9, 2010 at 3:39 PM, Devin Teske wrote:
>
...
> Should this really be set to something other than 0 or 1 by the
> end-user's environment? This would simplify a lot of return/exit
> calls...
>
> A scenario that I envision that almost never arises, but...
>
Forgive me for this top posting but I don't want to risk ruining the perfect
flow of Garret's analysis.
I read through it as if I was in a classroom lecture.
I have a special folder in kmail called "FreeBSD Tops" where I put mail that
makes me discover something unknown to me about FBSD, and t
On Oct 9, 2010, at 1:25 PM, Garrett Cooper wrote:
> On Wed, Oct 6, 2010 at 8:29 PM, Devin Teske wrote:
>>
>> On Oct 6, 2010, at 4:09 PM, Brandon Gooch wrote:
>>
>>> On Wed, Oct 6, 2010 at 3:45 PM, Devin Teske wrote:
Hello fellow freebsd-hackers,
Long-time hacker, first-time po
On Wed, Oct 6, 2010 at 8:29 PM, Devin Teske wrote:
>
> On Oct 6, 2010, at 4:09 PM, Brandon Gooch wrote:
>
>> On Wed, Oct 6, 2010 at 3:45 PM, Devin Teske wrote:
>>> Hello fellow freebsd-hackers,
>>>
>>> Long-time hacker, first-time poster.
>>>
>>> I'd like to share a shell script that I wrote for
On Sat, Oct 9, 2010 at 10:36 AM, Devin Teske wrote:
>
> On Oct 9, 2010, at 10:03 AM, Garrett Cooper wrote:
>
>> On Thu, Oct 7, 2010 at 12:54 AM, Julian Elischer wrote:
>>> On 10/7/10 12:23 AM, jhell wrote:
Alright thank you for your explanation. I do not normally see this usage
an
On Oct 9, 2010, at 10:03 AM, Garrett Cooper wrote:
> On Thu, Oct 7, 2010 at 12:54 AM, Julian Elischer wrote:
>> On 10/7/10 12:23 AM, jhell wrote:
>>>
>>> Alright thank you for your explanation. I do not normally see this usage
>>> and this just sort of stood out at me and I did not want to ass
On Thu, Oct 7, 2010 at 12:54 AM, Julian Elischer wrote:
> On 10/7/10 12:23 AM, jhell wrote:
>>
>> Alright thank you for your explanation. I do not normally see this usage
>> and this just sort of stood out at me and I did not want to assume what
>> you were trying to accomplish, without asking.
>
On 7.10.2010 15:42, Warren Block wrote:
Consider also the docs that tell the user to
echo 'something_enable="YES"' >> /etc/rc.conf
which can produce duplicate and possibly differing entries. Or
non-working entries if there was no ending \n present, or even a broken
like forgetting to add two '
On Thu, 2010-10-07 at 17:36 +0200, Stefan Esser wrote:
> Am 07.10.2010 05:29, schrieb Devin Teske:
> >
> > On Oct 6, 2010, at 4:09 PM, Brandon Gooch wrote:
> >
> >> On Wed, Oct 6, 2010 at 3:45 PM, Devin Teske wrote:
> >>> Hello fellow freebsd-hackers,
> >>>
> >>> Long-time hacker, first-time pos
Warren> Consider also the docs that tell the user to
Warren>echo 'something_enable="YES"' >> /etc/rc.conf
Warren> which can produce duplicate and possibly differing entries.
Yup! Which is exactly why I like the idea of this tool.
___
freebsd-hacker
On Thu, 7 Oct 2010, Douglas K. Rand wrote:
I think that this script might also fill a void with using Puppet as a
configuration tool. Currently Puppet, as its default behaviour, uses
files in /etc/rc.conf.d to set variables. I've found this approach
really lacking because you cannot do things li
I think that this script might also fill a void with using Puppet as a
configuration tool. Currently Puppet, as its default behaviour, uses
files in /etc/rc.conf.d to set variables. I've found this approach
really lacking because you cannot do things like:
nfs_server_enable="YES"
via a /etc/rc.
On 10/7/10 12:23 AM, jhell wrote:
Alright thank you for your explanation. I do not normally see this usage
and this just sort of stood out at me and I did not want to assume what
you were trying to accomplish, without asking.
three useage cases come to mind immediately.
1/ use within other s
On 10/07/2010 01:47, Devin Teske wrote:
>
> On Oct 6, 2010, at 9:49 PM, jhell wrote:
>
>> On 10/06/2010 23:29, Devin Teske wrote:
>>
>> I see no real advantage
>
> If you had to administer thousands of FreeBSD systems, you would.
>
Normally I have found large scale (1000's) of Unix like syste
On Oct 6, 2010, at 9:49 PM, jhell wrote:
> On 10/06/2010 23:29, Devin Teske wrote:
>
> I see no real advantage
If you had to administer thousands of FreeBSD systems, you would.
This script is obviously targeted to those for which are mentioned in the
header... "system administrators, power-us
On 10/06/2010 23:29, Devin Teske wrote:
I am not saying this to sound like I am shooting down this script but
from the looks of it, I see no real advantage over the way a FreeBSD
system is configured already. You could probably point these out though.
With that noted what advantage does this scri
On Oct 6, 2010, at 8:29 PM, Devin Teske wrote:
>
> On Oct 6, 2010, at 4:09 PM, Brandon Gooch wrote:
>
>> On Wed, Oct 6, 2010 at 3:45 PM, Devin Teske wrote:
>>> Hello fellow freebsd-hackers,
>>>
>>> Long-time hacker, first-time poster.
>>>
>>> I'd like to share a shell script that I wrote fo
On Oct 6, 2010, at 4:09 PM, Brandon Gooch wrote:
> On Wed, Oct 6, 2010 at 3:45 PM, Devin Teske wrote:
>> Hello fellow freebsd-hackers,
>>
>> Long-time hacker, first-time poster.
>>
>> I'd like to share a shell script that I wrote for FreeBSD system
>> administration.
>>
>
> It seems the list
34 matches
Mail list logo
