"And" extended matching operator
Hi everyone, Would it be possible to add another extended matching operator to already supported ones? It's just we have "or" in @() and "not (or)" in !(), but no "and". And combining patterns without it is awkward. If I want to say "a and not b", I have to write "not (not a or c)", like this: !(!(a)|c) If we had "and" operator, say written like &(), it would be possible to write it as is instead: &(a|!(c)) which would be more readable. Is there a chance to have such an operator added? Thank you. Sincerely, Nick
Re: "And" extended matching operator
On 11/28/2012 04:58 PM, Nikolai Kondrashov wrote: Would it be possible to add another extended matching operator to already supported ones? It's just we have "or" in @() and "not (or)" in !(), but no "and". And combining patterns without it is awkward. If I want to say "a and not b", I have to write "not (not a or c)", like this: !(!(a)|c) If we had "and" operator, say written like &(), it would be possible to write it as is instead: &(a|!(c)) which would be more readable. Is there a chance to have such an operator added? Or would it be more suitable to add support for '&' separator in the matching operators instead? So "a and not b" could look like this: @(a&!(b)) This leaves the possibility of using a mix of '&' and '|' separators in the operators, but maybe we could state that they have equal precedence, which would make the implementation simpler. Sincerely, Nick
Cron jobs, env vars, and group ID ... oh my
Hi, I need to run a script via cron that in turn launches a script to set up the requisite environment variables needed for a successive script that is called. Moreover, I need to change my group ID in order for the scripts called within the cron job to run properly. I have included a representation of my script below. It turns out that within my cron script, I am not seeing my group ID being changed (I call "id" for debug purposes). And even more puzzling is the behavior I'm seeing with the environment variables. I am using a here-document so that once the environment variables are set by "setUpEnvVars" (see below) they can be accessed by the successive calls (Note: Those calls are replaced by debug statements in the script below). When I echo or use the environment variables, they appear unset. Although, printenv correctly lists the environment variables with proper values. Environment variables that get set up via my profile (like $HOME) _are_ accessible within my here-document. In summary, I need help with two things: 1. How can I change my group ID within the cron script so that it applies to all successive calls--specifically within the here-document. 2. How can I access the environment variables set up by "setUpEnvVars" (see below) within the here-document? If I am approaching this problem incorrectly, please let me know. -- Delimiter BEGIN #! /bin/bash newgrp group1 id -g -n // This shows my login group ID, not group1 export SHELL="/bin/bash -i" /path/setUpEnvVars arg1 arg2 &> /home/mun/out.log <
Re: Cron jobs, env vars, and group ID ... oh my
On Wed, Nov 28, 2012 at 09:10:02AM -0800, Mun wrote: > I need to run a script via cron that in turn launches a script to set up the > requisite environment variables needed for a successive script that is called. > Moreover, I need to change my group ID in order for the scripts called within > the cron job to run properly. This belongs on help-bash, not bug-bash. > #! /bin/bash > > newgrp group1 > id -g -n // This shows my login group ID, not group1 Ah, the fundamental question here is "how does newgrp(1) work". Quoting the HP-UX man page: The newgrp command changes your group ID without changing your user ID and replaces your current shell with a new one. And a demonstration (from bash): imadev:~$ id uid=563(wooledg) gid=22(pgmr) groups=1002(webauth),208(opgmr) imadev:~$ echo $$ 8282 imadev:~$ newgrp opgmr imadev:~$ echo $$ 4859 imadev:~$ id uid=563(wooledg) gid=208(opgmr) groups=22(pgmr),1002(webauth) imadev:~$ exit imadev:~$ echo $$ 8282 So, you can see that this is utterly useless in a script. Try using sudo(1) instead if it's available. P.S., newgrp works very differently from within ksh, where it is a shell builtin. Still useless in a script, though.
Re: Cron jobs, env vars, and group ID ... oh my
Mun wrote: > #! /bin/bash > newgrp group1 > id -g -n // This shows my login group ID, not group1 The 'newgrp' command spawns a new child shell. After that child shell exits the new group evaporates. The rest of the script continues with the previous id. This is a common misunderstanding of how newgrp works. People often think it changes the current shell. It does not. It stacks a child shell. Basically, newgrp does not do what you thought it did. It can't be used in this way. You might try having the newgrp shell read commands from a secondary file. newgrp group1 < other-script-file Or you might consider using 'sudo' or 'su' for that purpose too. Bob
Re: Cron jobs, env vars, and group ID ... oh my
Hi Greg, Bob, Thanks for your replies. Please see my comments below. On Wed, Nov 28, 2012 at 09:50 AM PST, Greg Wooledge wrote: GW> On Wed, Nov 28, 2012 at 09:10:02AM -0800, Mun wrote: GW> > I need to run a script via cron that in turn launches a script to set up the GW> > requisite environment variables needed for a successive script that is called. GW> > Moreover, I need to change my group ID in order for the scripts called within GW> > the cron job to run properly. GW> GW> This belongs on help-bash, not bug-bash. Oops, my apologies; I forgot about the help-bash list. I will post a variant of my original post to help-bash (without this group ID problem, since you folks have addressed that issue already). GW> > #! /bin/bash GW> > GW> > newgrp group1 GW> > id -g -n // This shows my login group ID, not group1 GW> GW> Ah, the fundamental question here is "how does newgrp(1) work". I see. I will try Bob's suggestion to read input from another file. Best regards, -- Mun GW> GW> Quoting the HP-UX man page: GW> GW> The newgrp command changes your group ID without changing your user ID GW> and replaces your current shell with a new one. GW> GW> And a demonstration (from bash): GW> GW> imadev:~$ id GW> uid=563(wooledg) gid=22(pgmr) groups=1002(webauth),208(opgmr) GW> imadev:~$ echo $$ GW> 8282 GW> imadev:~$ newgrp opgmr GW> imadev:~$ echo $$ GW> 4859 GW> imadev:~$ id GW> uid=563(wooledg) gid=208(opgmr) groups=22(pgmr),1002(webauth) GW> imadev:~$ exit GW> imadev:~$ echo $$ GW> 8282 GW> GW> So, you can see that this is utterly useless in a script. Try using GW> sudo(1) instead if it's available. GW> GW> P.S., newgrp works very differently from within ksh, where it is a GW> shell builtin. Still useless in a script, though.
