Re: sysrc -- a sysctl(8)-like utility for managing /etc/rc.conf et. al.
> 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 using ! on Solaris ksh recently (not using test), > > and I agree that your example below is more straightforward and > > readable than the other examples I've dealt with in the past. > > > Ah that reminds me for the reason for "X$foo" = "X" but grasshopper, in Version 6 there was no test(1), hence the x$1 = x > > it's in case $foo evaluates to "-n" or similar... > > It's been a long time... but these days a data misevaluation leads to > such things ad SQL injection attacks > and I see no reason that a shell injection attack shouldn't be possible. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Timestamps in static libraries
Den 06/10/2010 kl. 14.35 skrev Erik Cederstrand:
> Den 06/10/2010 kl. 13.07 skrev Erik Cederstrand:
>
>> Is something like the following acceptable? Without risking changes to
>> buildworld/distribution just now, this would allow me to dump contents of an
>> archive and re-insert them with '0' for mtime, uid and gid before checking
>> checksums, without affecting normal ar behaviour.
>
> Great, I didn't even see the discussion on this list recently:
> http://lists.freebsd.org/pipermail/freebsd-hackers/2010-September/033005.html
>
> Anyway, I added file mode to the patch. Apparently recent binutils also added
> this feature. I haven't looked at their patch, but chance has it I used the
> same option '-D'.
>
> I'm sure the file mode I'm setting in line 175 of write.c is wrong (obj->md =
> 100644), but I couldn't quite figure out how to set the value to rw-r--r--.
> Here's the new patch:
>
> Index: ar.1
> ===
> --- ar.1 (revision 213478)
> +++ ar.1 (working copy)
> @@ -62,6 +62,7 @@
> .Op Fl a Ar position-after
> .Op Fl b Ar position-before
> .Op Fl c
> +.Op Fl D
> .Op Fl i Ar position-before
> .Op Fl j
> .Op Fl s
> @@ -179,6 +180,14 @@
> .Ar archive .
> The archive's symbol table, if present, is updated to reflect
> the new contents of the archive.
> +.It Fl D
> +When used in combination with the
> +.Fl r
> +option, insterts 0's instead of the real mtime, uid and gid values
> +and 644 instead of file mode from the members named by arguments
> +.Ar files ... .
> +This ensures that checksums on the resulting archives are reproducible
> +when member contents are identical.
> .It Fl f
> Synonymous with option
> .Fl T .
> Index: ar.c
> ===
> --- ar.c (revision 213478)
> +++ ar.c (working copy)
> @@ -154,7 +154,7 @@
> }
> }
>
> - while ((opt = getopt_long(argc, argv, "abCcdfijlMmopqrSsTtuVvxz",
> + while ((opt = getopt_long(argc, argv, "abCcdDfijlMmopqrSsTtuVvxz",
> longopts, NULL)) != -1) {
> switch(opt) {
> case 'a':
> @@ -173,6 +173,9 @@
> case 'd':
> set_mode(bsdar, opt);
> break;
> + case 'D':
> + bsdar->options |= AR_D;
> + break;
> case 'f':
> case 'T':
> bsdar->options |= AR_TR;
> @@ -357,8 +360,8 @@
> (void)fprintf(stderr, "\tar -m [-Tabijsvz] position archive file
> ...\n");
> (void)fprintf(stderr, "\tar -p [-Tv] archive [file ...]\n");
> (void)fprintf(stderr, "\tar -q [-Tcjsvz] archive file ...\n");
> - (void)fprintf(stderr, "\tar -r [-Tcjsuvz] archive file ...\n");
> - (void)fprintf(stderr, "\tar -r [-Tabcijsuvz] position archive file
> ...\n");
> + (void)fprintf(stderr, "\tar -r [-TcDjsuvz] archive file ...\n");
> + (void)fprintf(stderr, "\tar -r [-TabcDijsuvz] position archive file
> ...\n");
> (void)fprintf(stderr, "\tar -s [-jz] archive\n");
> (void)fprintf(stderr, "\tar -t [-Tv] archive [file ...]\n");
> (void)fprintf(stderr, "\tar -x [-CTouv] archive [file ...]\n");
> Index: ar.h
> ===
> --- ar.h (revision 213478)
> +++ ar.h (working copy)
> @@ -43,6 +43,7 @@
> #define AR_U 0x0200 /* only extract or update newer members.*/
> #define AR_V 0x0400 /* verbose mode */
> #define AR_Z 0x0800 /* gzip compression */
> +#define AR_D 0x1000 /* insert members with dummy mode, mtime, uid
> and gid */
>
> #define DEF_BLKSZ 10240 /* default block size */
>
> Index: write.c
> ===
> --- write.c (revision 213478)
> +++ write.c (working copy)
> @@ -163,11 +163,23 @@
> if (mtime != 0 && bsdar->options & AR_U && sb.st_mtime <= mtime)
> goto giveup;
>
> - obj->uid = sb.st_uid;
> - obj->gid = sb.st_gid;
> - obj->md = sb.st_mode;
> + /*
> + * When option '-D' is specified, mtime and UID / GID from the file
> + * will be replaced with 0, and file mode with 644. This ensures that
> + * checksums will match for two archives containing the exact same
> files.
> + */
> + if (bsdar->options & AR_D) {
> + obj->uid = 0;
> + obj->gid = 0;
> + obj->mtime = 0;
> + obj->md = 100644;
> + } else {
> + obj->uid = sb.st_uid;
> + obj->gid = sb.st_gid;
> + obj->mtime = sb.st_mtime;
> + obj->md = sb.st_mode;
> + }
> obj->size = sb.st_size;
> - obj->mtime = sb.st_mtime;
> obj->dev = sb.st_dev;
> obj->ino = sb.st_ino;
>
> @@ -621,7 +633,10 @@
> bsdar->options & AR_S) {
> entry = archive_entry_new();
Deterministic builds?
Hi hackers As a followup to the "Timestamps in static libraries" thread which resulted in a '-D' option to ar(1), I'd like to discuss if it is a worthy goal of the Project to create deterministic builds. By that I mean for two make build+install world+kernel+distribution runs, every contained file is bitwise identical between the two runs. Deterministic builds would be useful for me, since I'm creating binary diffs against lots of FreeBSD builds, and smaller diffs are good. Also, I'd like to detect which files have changed between two commits. I imagine it would also be useful for things like IDS and freebsd-update. Currently, this does not hold for static libraries (*.a), kernel modules (*.ko / *.ko.symbols) and the following: bthidd cc1 cc1obj cc1plus clang clang++ ctfconvert freebsd.cf freebsd.submit.cf kernel kernel.symbols libcrypto.so.6 libufs.so.5 loader pxeboot sendmail.cf submit.cf tblgen zfsloader Most of the libraries can be brought to be identical by using ar -D. Some record the absolute OBJDIR path to header files, though (libc.a for example). I tried adding 'D' to ARFLAGS in share/mk/sys.mk, but that's only part of the solution. ARFLAGS are overridden hundreds of places in the source code, and in some places ARFLAGS isn't even used (or AR for that matter). Is it worthwhile to go through the whole tree, fixing up these calls to ar? A lot of this is in contrib/ code. Another option is to add a WITH_DETERMINISTIC_AR knob to the build to compile ar with D as default behaviour. This would make the above changes unnecessary, but is more intrusive. A third option is that this is not a priority for the community, or directly unwanted, and that I just post-process my builds myself. I don't know what causes the checksum difference in .ko files - there is no size difference, and no difference according to strings(1). A bsdiff on the two is typically around 160B. .ko.symbols have some unique identifiers or addresses internally. kernel, loader, zfsloader and pxeboot have a build date recorded, kernel also has absolute path to GENERIC. OK for the kernel, I think, although it would be easier for me if this was just stored in a separate file since binary diffs on large files are expensive. clang, clang++ and tblgen store some absolute paths to .cpp files in the src repo internally, plus unique identifiers. freebsd.cf, freebsd.submit.cf, sendmail.cf and submit.cf record the absolute OBJDIR path to sendmail What do you think? Thanks, Erik
anyone got advice on sendmail and TLS on 8.1?
When I last did sendmail there wasn't any TLS/SSL stuff.
has anyone got an exact howto as to how to enable a simple sendmail
server?
all I want is:
TLS and authenticated email submission by me and my family
able to forward the email anywhere (maybe just to my ISP but who
knows) (outgoing)
non TLS submission from outside to reject all mail not to
elischer.{org,com}
and deliver our mail to mailboxes or gmail (or where-ever /etc/aliases
says.).
This is probably ALMOST a default configuration
but I can't be sure what is needed.. there are several
howtos on hte net but they are generally old and differ in details.
Julian
It's a simple enough request that he default sendmail install should
probably do it..
probably no need to move to postfix or anything.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: sysrc -- a sysctl(8)-like utility for managing /etc/rc.conf et. al.
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" > $ FAILURE=0 && sh failure.sh > FAILURE: > $ env FAILURE=0 sh failure.sh > FAILURE: 0 Ah, beautiful. I'd been searching for a way to set an environment variable prior to running a command in one-swift blow. I see env(1) is handy for that. Though honestly, the reason it's not working for you is because FAILURE has not been exported... $ while read LINE; do echo "$LINE" >> failure.sh; done #!/bin/sh echo "FAILURE: $FAILURE" ^D ### nifty way to create a file ^_^ $ cat failure.sh #!/bin/sh echo "FAILURE: $FAILURE" ### Yup, that's what we wrote to it. $ unset FAILURE ### Let's start clean $ FAILURE=0 && sh failure.sh FAILURE: ### No effect... (cause it's not exported yet) $ export FAILURE ### Should have an effect now, let's try $ FAILURE=0 && sh failure.sh FAILURE: 0 ### Success ... once it has been exported by name (with a value or not) it is always exported $ FAILURE=1 && sh failure.sh FAILURE: 1 ### no need to re-export, once exported by-name, new assignments are exported $ unset FAILURE ### Only way to get it to be unexported once exported $ FAILURE=0 && sh failure.sh FAILURE: ### Assignment no longer exported to sub-shells So, I guess an alternative to the usage of env(1) would be: export FAILURE=0 && sh failure.sh Works as expected... $ unset FAILURE $ export FAILURE=0 && sh failure.sh FAILURE: 0 Hence why when adding environment-variable based tunables in ~/.bashrc, it's best to use export (either after initial assignment or with assignment specified on export line in-one-go) else the assignment won't survive the script... Safe for four exceptions... 1. When the script itself executes the set(1) built-in with either `-a' flag or `-o allexport' arguments 2. The parent shell does the above and does not execute the child as a sub-shell but rather sources the child using the `.' built-in 3. The script itself has an invocation line resembling any of the following: #!/bin/sh -a #!/bin/sh -o allexport #!/usr/bin/env sh -a #!/usr/bin/env sh -o allexport 4. The parent shell does the above and does not execute the child as a sub-shell but rather sources the child using the `.' built-in. Which, in any of the above cases, simple assignment to a variable name will cause it to be exported to all children/sub-shell environments. Works for example in a live-shell too... $ unset FAILURE # start from a clean slate $ FAILURE=0 && sh failure.sh FAILURE: # Success, we're not exporting on bare assignment $ set -a # Turn on allexport in the interactive shell $ FAILURE=0 && sh failure.sh FAILURE: 0 # Success, we're exporting on bare-assignment due to allexport $ set +a # Turn off allexport in the interactive shell $ FAILURE=0 && sh failure.sh FAILURE: 0 # It was still exported $ unset FAILURE # Let's unexport it $ FAILURE=0 && sh failure.sh FAILURE: # success, no longer exported automatically via allexport feature > Understood. There really isn't any degree of shell style in FreeBSD, > but it would be nice if there was.. I find that to be the case quite often when dealing with shell scripting. I've been trying to bring a little style to the shell scripting world these days ^_^ >> Ah, coolness. command(1) is new to me just now ^_^ > > Yeah.. I was looking for something 100% portable after I ran into > issues with writing scripts for Solaris :). I went back to our legacy systems just now (FreeBSD-4.11) and tried this... $ uname -spr FreeBSD 4.11-STABLE i386 $ /bin/sh -c "command -v '['" command: unknown option: -v Meanwhile: $ uname -spr FreeBSD 8.1-RELEASE-p1 amd64 $ /bin/sh -c "command -v '['" [ So it would appear that on FreeBSD at least, type(1) built-in is more portable (this perhaps traces back to it's 4.4BSDLite roots). I was thinking ... perhaps another flag. But alas, -p was the only valid option back then, which only causes a default PATH to be used rather than an inherited one. > ... > >> If the variable expands to nothing, go ahead and let it. I've traced every >> possible expansion of variables when used in the following manner: >> [ "$VAR" ] ... >> and it never fails. If $VAR is anything but null, the entire expression will >> evaluate to true. >> Again... coming from 15+ years of perl has made my eyes read the following >> block of code: >> if [ "$the_network_is_enabled" ]; then >> aloud in my head as "if the network is enabled, then ..." (not too far of a >> stretch)... which has a sort of quintessential humanized logic to it, don't >> you think? >> Now, contrast that with this block: >> if [ "x$the_network_is_enabled" = x ]; then >> (one might verbalize that in their head as "if x plus `the network is >> enable
Re: sysrc -- a sysctl(8)-like utility for managing /etc/rc.conf et. al.
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_files" = x -o "x$varname" = x ]
>>> then
>>>return ${FAILURE-1}
>>> fi
>> I think you'll find (quite pleasantly) that if you intonate the lines...
>>
>> "rc_conf_files [is non-null] OR return failure"
>> "varname [is non-null] OR return failure"
>>
>> Sounds a lot better/cleaner than the intonation of the suggested replacement:
>>
>> "if x plus rc_conf_files expands to something that is not equal to x OR
>> x plus the expansion of varname is not x then return failure"
>>
>
>
> 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.
I agree... I think that the "x" syntax came around for when people were using
non-quoted syntax... for example...
[ x$foo = x ]
is still very useful in that it prevents the error when $foo expands to "-e".
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:
[ "-n" = x ]
rather than:
[ -n = x ]
The former not causing an error, while the latter does.
Quite functionally, at a C-level, if you have your array, ...
argv[0] = "[\0";
argv[1] = "\"-n\"\0"; /* quoted syntax */
argv[2] = "=\0";
argv[3] = "x\0";
and
argv[0] = "[\0";
argv[1] = "-n\0"; /* non-quoted syntax */
argv[2] = "=\0";
argv[3] = "x\0";
The C-code that switch'es on the argv element can tell the difference between a
leading quote and a leading dash and does indeed do the right thing for all
expansions of the variable within a double-quote block ("...").
Though, the non-quoted syntax should be avoided at all costs, imho unless you
know for a fact that the expansion of the variable will never include a
character from $IFS (defaults to space, tab, newline).
If it does, then it'll evaluate to a new positional argument for the C-code.
Take the following example:
$ foo="abc = abc"
$ [ $foo ] && echo true
true
$ foo="abc = 123"
$ [ $foo ] && echo true
# no output (not true)
Whereas the quoted syntax:
$ [ "$foo" ]
will always evaluate to true because there is an implied "-n" operator for the
case where the first-and-last positional argument is a double-quoted string,
and...
$ [ -n "$foo" ]
always evaluates to true in the above cases for foo ("abc = abc" then later
"abc = 123").
> ...
>
> Now One thing that should be bourne in mind (heh) is that
> as there is a 'usual' form of format for perl there is one for sh as well so
> it's not "polite"
> to make one's sh code look like perl. :-)
Perusing sh(1) today... found examples of the lazy operators:
[ expr ] || expr
[ expr ] && expr
Search under "Short-Circuit List Operators"
I'd say that the description therein is a green-light to treat sh like perl ^_^
> ___
> freebsd-hackers@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
--
Cheers,
Devin Teske
-> CONTACT INFORMATION <-
Business Solutions Consultant II
FIS - fisglobal.com
510-735-5650 Mobile
510-621-2038 Office
510-621-2020 Office Fax
909-477-4578 Home/Fax
devin.te...@fisglobal.com
-> LEGAL DISCLAIMER <-
This message contains confidential and proprietary information
of the sender, and is intended only for the person(s) to whom it
is addressed. Any use, distribution, copying or disclosure by any
other person is strictly prohibited. If you have received this
message in error, please notify the e-mail sender immediately,
and delete the original message without making a copy.
-> FUN STUFF <-
-BEGIN GEEK CODE BLOCK-
Version 3.1
GAT/CS d(+) s: a- C++() UB$ P++() L++() !E--- W++ N? o? K- w O
M+ V- PS+ PE Y+ PGP- t(+) 5? X+(++) R>++ tv(+) b+(++) DI+(++) D(+) G+>++ e>+ h
r>++ y+
--END GEEK CODE BLOCK--
http://www.geekcode.com/
-> END TRANSMISSION <-
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: sysrc -- a sysctl(8)-like utility for managing /etc/rc.conf et. al.
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: > $ env FAILURE=0 sh failure.sh > FAILURE: 0 > > Ah, beautiful. I'd been searching for a way to set an environment variable > prior to running a command in one-swift blow. I see env(1) is handy for > that. And the cool thing is that it works from other shells: $ export FOO=0; csh -c "env FOO=1 csh -c 'env | grep FOO'" FOO=1 That's why I prefer it in command line examples (it's deterministic). > Though honestly, the reason it's not working for you is because FAILURE has > not been exported... I didn't state it explicitly that way, but yes... that's what I was implying. ... > Hence why when adding environment-variable based tunables in ~/.bashrc, it's > best to use export (either after initial assignment or with assignment > specified on export line in-one-go) else the assignment won't survive the > script... Which makes sense because you're the developer, but does it make sense for production quality code, especially when users are better than developers at finding code flaws, i.e. doing the following: $ export FAILURE=a $ exit $FAILURE exit: Illegal number: a $ echo $? 2 Implementation in the shell may vary (again, this was /bin/sh). > Safe for four exceptions... > 1. When the script itself executes the set(1) built-in with either `-a' flag > or `-o allexport' arguments > 2. The parent shell does the above and does not execute the child as a > sub-shell but rather sources the child using the `.' built-in > 3. The script itself has an invocation line resembling any of the following: > #!/bin/sh -a > #!/bin/sh -o allexport > #!/usr/bin/env sh -a > #!/usr/bin/env sh -o allexport Hmm... forgot about that :D. > 4. The parent shell does the above and does not execute the child as a > sub-shell but rather sources the child using the `.' built-in. > Which, in any of the above cases, simple assignment to a variable name will > cause it to be exported to all children/sub-shell environments. > Works for example in a live-shell too... > $ unset FAILURE > # start from a clean slate > $ FAILURE=0 && sh failure.sh > FAILURE: > # Success, we're not exporting on bare assignment > $ set -a > # Turn on allexport in the interactive shell > $ FAILURE=0 && sh failure.sh > FAILURE: 0 > # Success, we're exporting on bare-assignment due to allexport > $ set +a > # Turn off allexport in the interactive shell > $ FAILURE=0 && sh failure.sh > FAILURE: 0 > # It was still exported > $ unset FAILURE > # Let's unexport it > $ FAILURE=0 && sh failure.sh > FAILURE: > # success, no longer exported automatically via allexport feature Part of the reason why I follow the set global once with empty values or defaults and declare locals given the chance and if I care. Otherwise there's too much wiggle room for surprises from the user's environment :). > Understood. There really isn't any degree of shell style in FreeBSD, > but it would be nice if there was.. > > I find that to be the case quite often when dealing with shell scripting. > I've been trying to bring a little style to the shell scripting world these > days ^_^ > > > Ah, coolness. command(1) is new to me just now ^_^ > > Yeah.. I was looking for something 100% portable after I ran into > issues with writing scripts for Solaris :). > > I went back to our legacy systems just now (FreeBSD-4.11) and tried this... > $ uname -spr > FreeBSD 4.11-STABLE i386 > $ /bin/sh -c "command -v '['" > command: unknown option: -v > Meanwhile: > $ uname -spr > FreeBSD 8.1-RELEASE-p1 amd64 > $ /bin/sh -c "command -v '['" > [ > So it would appear that on FreeBSD at least, type(1) built-in is more > portable (this perhaps traces back to it's 4.4BSDLite roots). > I was thinking ... perhaps another flag. But alas, -p was the only valid > option back then, which only causes a default PATH to be used rather than an > inherited one. Potentially. command(1) is just POSIX compatible, whereas type may be BSD compatible *shrugs*. ... > On legacy system: > $ uname -spr > FreeBSD 4.11-STABLE i386 > $ /bin/sh -c '[ "-n" ] && echo true' > true > $ /bin/sh -c '[ "-e" ] && echo true' > true > $ /bin/sh -c '[ "-z" ] && echo true' > true > $ /bin/sh -c '[ "-r" ] && echo true' > true > $ /bin/sh -c '[ "-f" ] && echo true' > true > $ /bin/sh -c '[ "-s" ] && echo true' > true > Up-to-date is the same: > $ uname -spr > FreeBSD 8.1-RELEASE-p1 amd64 > $ /bin/sh -c '[ "-n" ] && echo true' > true > $ /bin/sh -c '[ "-e" ] && echo true' > true > $ /bin/sh -c '[ "-z" ] && echo true' > true > $ /bin/sh -c '[ "-r" ] && echo true' > true > $ /bin/sh -c '[ "-f" ] && echo true' > true > $ /bin/sh -c '[ "-s" ] && echo true' > true Fair enough. My supposed knowledge and/or memory mislead me here :/. ... > and the `our' keyword
Re: sysrc -- a sysctl(8)-like utility for managing /etc/rc.conf et. al.
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: >> >> [ "-n" = x ] >> >> rather than: >> >> [ -n = x ] >> >> The former not causing an error, while the latter does. >> > The latter does not cause an error. Try it: > > # [ "-n" = x ] ; echo $? > 1 > > # [ -e = "no" ] ; echo $? > 1 > > # [ -e = -n ] ; echo $? > 1 Logical error, not functional error. >> Quite functionally, at a C-level, if you have your array, ... >> >> argv[0] = "[\0"; >> argv[1] = "\"-n\"\0"; /* quoted syntax */ >> argv[2] = "=\0"; >> argv[3] = "x\0"; >> >> and >> >> argv[0] = "[\0"; >> argv[1] = "-n\0"; /* non-quoted syntax */ >> argv[2] = "=\0"; >> argv[3] = "x\0"; >> >> > You won't see the double-quotes in the C program. Correct, an external C programming will get the arguments just like a shell script. > The shell processes single and double quotes, and passes the result to the > C program which is running. It might be different for built-in functions, Indeed it is. > but /bin/test would never see the double-quotes if they were used. And since > the built-in function has to work the same as standalone function There is no distinction between "built-in function" and "standalone function". I think you mean "built-in" versus "external binary". The way that parameters are passed off to the internal parser is different than the way arguments are passed to external executables. > , I doubt the built-in would be any different. > > # list_args "-n" > > list_args at 19:36:15 Oct 10: $# = 1 > ARG[000] l=002: '-n' > # list_args -n > > list_args at 19:36:22 Oct 10: $# = 1 > ARG[000] l=002: '-n' > > (note that the single-quotes you see there are printed by the list_args > script itself for display purposes). > > disclaimer: I think this is the first post that I've made with the new > "open-source edition" of Eudora, and I have no idea if this will be formatted > the way I'm expecting it be! > > -- > Garance Alistair Drosehn = dro...@rpi.edu > Senior Systems Programmer or g...@freebsd.org > Rensselaer Polytechnic Institute; Troy, NY; USA > -- Cheers, Devin Teske -> CONTACT INFORMATION <- Business Solutions Consultant II FIS - fisglobal.com 510-735-5650 Mobile 510-621-2038 Office 510-621-2020 Office Fax 909-477-4578 Home/Fax devin.te...@fisglobal.com -> LEGAL DISCLAIMER <- This message contains confidential and proprietary information of the sender, and is intended only for the person(s) to whom it is addressed. Any use, distribution, copying or disclosure by any other person is strictly prohibited. If you have received this message in error, please notify the e-mail sender immediately, and delete the original message without making a copy. -> FUN STUFF <- -BEGIN GEEK CODE BLOCK- Version 3.1 GAT/CS d(+) s: a- C++() UB$ P++() L++() !E--- W++ N? o? K- w O M+ V- PS+ PE Y+ PGP- t(+) 5? X+(++) R>++ tv(+) b+(++) DI+(++) D(+) G+>++ e>+ h r>++ y+ --END GEEK CODE BLOCK-- http://www.geekcode.com/ -> END TRANSMISSION <- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: sysrc -- a sysctl(8)-like utility for managing /etc/rc.conf et. al.
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-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: sysrc -- a sysctl(8)-like utility for managing /etc/rc.conf et. al.
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 which could get errors unless "x$foo" was used, but it's been more than 10 years since I last hit that situation. Of course, ever since I did hit it, I tend to write my 'test' parameters in ways which avoid the problem. It might have only been when checking if the variable was set to anything. Eg, using: if [ "$foo" ] ; then instead of: if [ -n "$foo" ] ; then ... Or it might have been when combining multiple checks in a single 'test' (using -a's, etc). However, I'm not going to try to dream up a pathological example of that right now. I agree... I think that the "x" syntax came around for when people were using non-quoted syntax... for example... [ x$foo = x ] is still very useful in that it prevents the error when $foo expands to "-e". The non-quoted example is dangerous in the case where $foo has multiple words in it. The "x" does not save you from that problem. I have a 'list_args' script which just lists out the parameters it is called with: # Test="this is a multi-word test" # list_args x$Test list_args at 19:22:27 Oct 10: $# = 5 ARG[000] l=005: 'xthis' ARG[001] l=002: 'is' ARG[002] l=001: 'a' ARG[003] l=010: 'multi-word' ARG[004] l=004: 'test' 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: [ "-n" = x ] rather than: [ -n = x ] The former not causing an error, while the latter does. The latter does not cause an error. Try it: # [ "-n" = x ] ; echo $? 1 # [ -e = "no" ] ; echo $? 1 # [ -e = -n ] ; echo $? 1 Quite functionally, at a C-level, if you have your array, ... argv[0] = "[\0"; argv[1] = "\"-n\"\0"; /* quoted syntax */ argv[2] = "=\0"; argv[3] = "x\0"; and argv[0] = "[\0"; argv[1] = "-n\0"; /* non-quoted syntax */ argv[2] = "=\0"; argv[3] = "x\0"; You won't see the double-quotes in the C program. The shell processes single and double quotes, and passes the result to the C program which is running. It might be different for built-in functions, but /bin/test would never see the double-quotes if they were used. And since the built-in function has to work the same as standalone function, I doubt the built-in would be any different. # list_args "-n" list_args at 19:36:15 Oct 10: $# = 1 ARG[000] l=002: '-n' # list_args -n list_args at 19:36:22 Oct 10: $# = 1 ARG[000] l=002: '-n' (note that the single-quotes you see there are printed by the list_args script itself for display purposes). /disclaimer: I think this is the first post that I've made with the new "open-source edition" of Eudora, and I have no idea if this will be formatted the way I'm expecting it be!/ -- Garance Alistair Drosehn = dro...@rpi.edu Senior Systems Programmer or g...@freebsd.org Rensselaer Polytechnic Institute; Troy, NY; USA ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Run queue questions
How would the scheduling overhead and the system performance be affected when the total number of run queues is reduced from 64 to 32? -- Eknath Venkataramani ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: sysrc -- a sysctl(8)-like utility for managing /etc/rc.conf et. al.
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. I know that. What I'm saying is that the command works as you'd want it to work. It does not hit a parsing error. The double-quotes did not change how the command behaved. You deleted the context of what I was replying to when I said the above. Looking at the examples I gave there, it probably would have been clearer if I had typed the exact same command with and without the double-quotes. Eg: 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: > > [ "-n" = x ] > > rather than: > > [ -n = x ] > > The former not causing an error, while the latter does. Your second example does not cause an error. Try it: # [ "-n" = "-n" ] ; echo $? 0 # [ "-n" = x ] ; echo $? 1 Compared to the double-quote-less: # [ -n = "-n" ] ; echo $? 0 # [ -n = x ] ; echo $? 1 -- Garance ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: sysrc -- a sysctl(8)-like utility for managing /etc/rc.conf et. al.
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 of return/exit
>> calls...
>
> A scenario that I envision that almost never arises, but...
>
> Say someone wanted to call my script but wanted to mask it to always return
> with success (why? I dunno... it's conceivable though).
>
> Example: (this should be considered ugly -- because it is)
>
> FAILURE=0 && sysrc foo && reboot
Wouldn't this bork functions used inside a conditional?
: ${FAILURE:=1}
foo() { return ${FAILURE-1}; }
if ! foo; then
echo good
else
echo error
fi
$ test.sh
good
$ FAILURE=0 test.sh
error
I think only sysrc_set() is affected, though.
if sysrc_set "$NAME" "${1#*=}"; then
echo " -> $( sysrc "$NAME" )"
fi
$ sysrc hostname=blah
hostname: raphael.local
sysrc: cannot create /etc/rc.conf: permission denied
$ FAILURE=0 sh sysrc hostname=blah
hostname: raphael.local
sysrc: cannot create /etc/rc.conf: permission denied
-> raphael.local
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: issue with unsetting 'arch' flag
On Thu, Oct 7, 2010 at 3:36 AM, Alexander Best wrote: > On Wed Oct 6 10, Garrett Cooper wrote: >> On Wed, Oct 6, 2010 at 4:03 PM, Garrett Cooper wrote: >> > On Wed, Oct 6, 2010 at 3:01 PM, Sergey Kandaurov wrote: >> >> On 6 October 2010 23:38, Alexander Best wrote: >> >>> On Wed Oct 6 10, Garrett Cooper wrote: >> On Wed, Oct 6, 2010 at 10:35 AM, Alexander Best >> wrote: >> > On Wed Oct 6 10, Garrett Cooper wrote: >> >> On Tue, Oct 5, 2010 at 4:50 PM, Alexander Best >> >> wrote: >> >> > hi there, >> >> > >> >> > i think the following example shows the problem better than a long >> >> > explanation: >> >> > >> >> > `touch ftest && chflags arch ftest && chflags -vv 0 ftest`. >> >> > ^^non-root ^^root ^^non-root >> >> > >> >> > chflags claims to have cleared the 'arch' flag (which should be >> >> > impossible as >> >> > non-root user), but indeed has done nothing. >> >> > >> >> > i've tried the same with 'sappnd' and that works as can be >> >> > expected. >> >> > >> >> > The issue was confirmed to exist in HEAD (me), stable/8 >> >> > (pgollucc1, jpaetzel) >> >> > and stable/7 (nox). >> >> > On stable/6 it does NOT exist (jpaetzel). chflags properly fails >> >> > with EPERM. >> >> >> >> Fails for me when I call the syscall directly, as I would expect, >> >> and passes when I'm superuser: >> >> >> >> $ ./test_chflags >> >> (uid, euid) = (1000, 1000) >> >> test_chflags: chflags: Operation not permitted >> >> test_chflags: lchflags: Operation not permitted >> >> $ sudo ./test_chflags >> >> (uid, euid) = (0, 0) >> >> >> >> According to my basic inspection in strtofflags >> >> (.../lib/libc/gen/strtofflags.c), it works as well. >> >> And last but not least, executing the commands directly on the >> >> CLI work: >> >> >> >> $ tmpfile=`mktemp /tmp/chflags.XX` >> >> $ chflags arch $tmpfile >> >> chflags: /tmp/chflags.nQm1IL: Operation not permitted >> >> $ rm $tmpfile >> >> $ tmpfile=`mktemp /tmp/chflags.XX` >> >> $ sudo chflags arch $tmpfile >> >> $ sudo chflags noarch $tmpfile >> >> $ rm $tmpfile >> > >> > thanks for your test app and helping out with this problem. i'm not >> > sure >> > however you understood the problem. probably i didn't explain it >> > right: >> > >> > $ sudo rm -d /tmp/chflags.XX >> > $ tmpfile=`mktemp /tmp/chflags.XX` >> > $ sudo chflags arch $tmpfile >> > $ chflags noarch $tmpfile >> > >> > is what's causing the problem. the last chflags call should fail, but >> > it >> > doesn't. >> >> Sorry... my CLI based example was stupid. I meant: >> >> $ tmpfile=`mktemp /tmp/chflags.XX` >> $ chflags arch $tmpfile >> chflags: /tmp/chflags.V2NpXR: Operation not permitted >> $ chflags noarch $tmpfile >> $ rm $tmpfile >> >> Currently chflags(2) states: >> >> The SF_IMMUTABLE, SF_APPEND, SF_NOUNLINK, and SF_ARCHIVED flags >> may only >> be set or unset by the super-user. Attempts to set these flags by >> non- >> super-users are rejected, >>> attempts by non-superusers to clear >> flags that >> are already unset are silently ignored. <<< These flags may be >> set at any >> time, but normally may only be unset when the system is in >> single-user >> mode. (See init(8) for details.) >> >> So this behavior is already well documented :). The EPERM section >> should really note SF_ARCHIVED though (whoever added the flag forgot >> to add that particular item to the ERRORS section). >> >>> >> >>> that's perfectly alright. clearing an unset flag shouldn't cause any >> >>> error to >> >>> be returned. however in my example arch *does* get set and still trying >> >>> to >> >>> unset it as normal user doesn't return an error. >> >>> >> >> >> >> It's even more interesting. >> >> >> >> As far as I could parse the code: >> >> - UFS has no special handling for SF_ARCHIVED (I found only it for >> >> msdosfs) >> > >> > _very_ interesting: >> > >> > [/sys]$ grep -r SF_ARCHIVED kern/ fs/ ufs/ | grep -v svn >> > fs/msdosfs/msdosfs_vnops.c: vap->va_flags |= SF_ARCHIVED; >> > fs/msdosfs/msdosfs_vnops.c: if (vap->va_flags & ~SF_ARCHIVED) >> > fs/msdosfs/msdosfs_vnops.c: if (vap->va_flags & SF_ARCHIVED) >> > >> > The commit that introduced this change probably wasn't doing the >> > right thing: >> > http://svn.freebsd.org/viewvc/base/head/sys/fs/msdosfs/msdosfs_vnops.c?revision=5241&view=markup >> > ; cp(1) probably should have been fixed in lieu of `fixing' msdosfs. >> > >> >> - ufs_setattr() does not handle unsetting SF_ARCHIVED, >> >> so al
Re: sysrc -- a sysctl(8)-like utility for managing /etc/rc.conf et. al.
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 tests would fare the same for all of the >> above? > > .../sys/kern/kern_sysctl.c says otherwise (look for the comment above > the sysctllock declaration). The locking is just hidden from the > developer/end-user. > >> Here's what I'm thinking we should do to solve this... >> Since the atomicity of the write operation is anything-but singular >> (meaning, it takes incrementally larger blocks of time to write larger >> amounts of data, increasing the risk-curve for failure to occur by two >> operations coinciding at the same time -- I'm truly sorry, my wife has me >> helping her with her business statistics II course, forgive me, I'll >> clarify). > > ... > > I think I said it before, but yes.. I completely agree with the > atomicity approach. I prefer `mktemp /tmp/XX' because it would do > nothing more than potentially clutter up /tmp if the operation fails > for whatever reason (instead of /etc), and it's less of a security > concern. I suppose that's less of a problem though, because if someone > has the ability to write to /etc, then all bets are off, but the > clutter part is a bit annoying.. I checked out mktemp(1)... just what the doctor ordered for preventing race-conditions. And it's in the base FreeBSD distribution even back as far as FreeBSD-4.11 (likely much further; but that's what I checked). > ... > > I would just hold to this statement in /etc/defaults/rc.conf: > > # All arguments must be in double or single quotes. > > and also state: > > "this tool functions based on the idea that the rc.conf files are > simply written, and can be evaluated as standalone configuration data. > Anything that doesn't conform to these requirements isn't guaranteed > to work with the tool in all cases" Simpler is indeed better ^_^ > > Thanks! > -Garrett > ___ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org" -- Cheers, Devin Teske -> CONTACT INFORMATION <- Business Solutions Consultant II FIS - fisglobal.com 510-735-5650 Mobile 510-621-2038 Office 510-621-2020 Office Fax 909-477-4578 Home/Fax devin.te...@fisglobal.com -> LEGAL DISCLAIMER <- This message contains confidential and proprietary information of the sender, and is intended only for the person(s) to whom it is addressed. Any use, distribution, copying or disclosure by any other person is strictly prohibited. If you have received this message in error, please notify the e-mail sender immediately, and delete the original message without making a copy. -> FUN STUFF <- -BEGIN GEEK CODE BLOCK- Version 3.1 GAT/CS d(+) s: a- C++() UB$ P++() L++() !E--- W++ N? o? K- w O M+ V- PS+ PE Y+ PGP- t(+) 5? X+(++) R>++ tv(+) b+(++) DI+(++) D(+) G+>++ e>+ h r>++ y+ --END GEEK CODE BLOCK-- http://www.geekcode.com/ -> END TRANSMISSION <- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
