On Wed, Feb 27, 2008 at 11:13 AM, Garrick Staples <[EMAIL PROTECTED]> wrote:
>
> 'name=val >$name' is a weird case that I can't explain. It is not related to
> 'name=val command' because there is no command. It acts like two statements
> when syntacticaly it is one. It think it is a bug. Avo
On Wed, Feb 27, 2008 at 11:46:13AM -0600, Les Mikesell alleged:
> Stephen Harris wrote:
>
> >>Yes, but I'm looking for what happens before and after. Why does
> >>unset foo
> >>foo=bar >$foo
> >>do something you might expect, but
> >>unset foo
> >>foo=bar echo $foo >$foo
> >>doesn't?
> >
> >What
Stephen Harris wrote:
Yes, but I'm looking for what happens before and after. Why does
unset foo
foo=bar >$foo
do something you might expect, but
unset foo
foo=bar echo $foo >$foo
doesn't?
What would you expect the last to do? "foo=bar echo $foo" only sets "foo"
inside the scope of the "echo
Here's a little script that I have to play around with positional
parameters. I'm pretty certain I did not author this one but got it
either off the web or ina book. I added a line of comment in it but
I don't believe I made any other contributions to it.
Jacques B.
#!/bin/bash
# arglist.sh
#
On Tue, Feb 26, 2008 at 11:16:27PM -0600, Les Mikesell wrote:
> Yes, but I'm looking for what happens before and after. Why does
> unset foo
> foo=bar >$foo
> do something you might expect, but
> unset foo
> foo=bar echo $foo >$foo
> doesn't?
What would you expect the last to do? "foo=bar echo
On Tue, Feb 26, 2008 at 11:16:27PM -0600, Les Mikesell alleged:
> Yes, but I'm looking for what happens before and after. Why does
> unset foo
> foo=bar >$foo
This is interesting. I would have guessed a syntax error. I was surprised
when it worked.
This is a special case because there isn't a
Garrick Staples wrote:
On Tue, Feb 26, 2008 at 05:13:12PM -0600, Les Mikesell alleged:
Garrick Staples wrote:
On Tue, Feb 26, 2008 at 04:33:30PM -0600, Les Mikesell alleged:
Does anyone have a quick reference to the order of operations as the
shell parses a command line (variable parsing,i/o r
On Tue, Feb 26, 2008 at 05:13:12PM -0600, Les Mikesell alleged:
> Garrick Staples wrote:
> >On Tue, Feb 26, 2008 at 04:33:30PM -0600, Les Mikesell alleged:
> >>Does anyone have a quick reference to the order of operations as the
> >>shell parses a command line (variable parsing,i/o redirection, wi
On Tue, Feb 26, 2008 at 03:30:02PM -0800, Benjamin Smith alleged:
> File script3.sh contains the following:
> $ cat script3.sh
> #! /bin/sh
> for file in $*
> do
> ls -l "$file";
> done
Use "$@" instead of $*. It will split up the way you want.
pgpniM2ihOWs1.pgp
Desc
On Tue, Feb 26, 2008 at 03:30:02PM -0800, Benjamin Smith wrote:
> Exactly. Here's my example:
>
> $ ls -laFd *
You're doing it wrong:
ls -laFD -- *
> ls -l "$file";
You're doing it wrong:
ls -l -- "$file"
> $ /bin/bash ./script3.sh *
You're doing it wrong:
bash ./script3.sh "*"
On Tuesday 26 February 2008, Les Mikesell wrote:
> Benjamin Smith wrote:
> > > Unless I'm terribly mistaken (again?), the only way I've been able to
> > see "loop thru a list of files" work reliably is with "find" using
> > the "-print0" option, in cahoots with xargs.
> >
> > Is there any other
Stephen Harris wrote:
On Tue, Feb 26, 2008 at 04:33:30PM -0600, Les Mikesell wrote:
Benjamin Smith wrote:
Unless I'm terribly mistaken (again?), the only way I've been able to
see "loop thru a list of files" work reliably is with "find" using
the "-print0" option, in cahoots with xargs.
Is t
On Tue, Feb 26, 2008 at 05:30:12PM -0500, Jacques B. wrote:
> If I understand you correctly, you are referring to the problem caused
> by spaces in filenames? Steve mentioned the environment variable IFS
> ("individual field separator" if memory serves me correctly). By
> default it's space, tab
On Tue, Feb 26, 2008 at 01:51:28PM -0800, Benjamin Smith wrote:
> Unless I'm terribly mistaken (again?), the only way I've been able to
> see "loop thru a list of files" work reliably is with "find" using
> the "-print0" option, in cahoots with xargs.
What is it you're trying to do? You typica
On Tue, Feb 26, 2008 at 04:33:30PM -0600, Les Mikesell wrote:
> Benjamin Smith wrote:
> >> Unless I'm terribly mistaken (again?), the only way I've been able to
> >see "loop thru a list of files" work reliably is with "find" using
> >the "-print0" option, in cahoots with xargs.
> >
> >Is there a
Garrick Staples wrote:
On Tue, Feb 26, 2008 at 04:33:30PM -0600, Les Mikesell alleged:
Does anyone have a quick reference to the order of operations as the
shell parses a command line (variable parsing,i/o redirection, wildcard
and variable expansion, splitting on IFS, quote removal, command
s
On Tue, Feb 26, 2008 at 04:33:30PM -0600, Les Mikesell alleged:
> Does anyone have a quick reference to the order of operations as the
> shell parses a command line (variable parsing,i/o redirection, wildcard
> and variable expansion, splitting on IFS, quote removal, command
> substitution etc.)
Benjamin Smith wrote:
> Unless I'm terribly mistaken (again?), the only way I've been able to
see "loop thru a list of files" work reliably is with "find" using
the "-print0" option, in cahoots with xargs.
Is there any other way?
for $file in wildcard*
do
ls -l "$file"
done
But thi
> Unless I'm terribly mistaken (again?), the only way I've been able to
> see "loop thru a list of files" work reliably is with "find" using
> the "-print0" option, in cahoots with xargs.
>
> Is there any other way?
>
>
> -Ben
> --
If I understand you correctly, you are referring to the prob
On Tuesday 26 February 2008, Bart Schaefer wrote:
> For someone who apparently has no idea what he's talking about, you
> sure say a lot.
Sorry. It's how I think aloud. Sorry if I offended.
> No, you missed it. You need the quotes *everywhere* that a variable
> is referenced.
Yes, I missed thi
On Tue, Feb 26, 2008 at 12:40:06PM -0800, Benjamin Smith wrote:
> In script2.sh, $1 only contains the string "this". There is no safe way to
> pass $1 (containing string "this parameter") from script1 to script2 as a
> single, trustable parameter.
The statement is meaningless. Trusted in WHAT
Benjamin Smith wrote:
On Tuesday 26 February 2008, Les Mikesell wrote:
WHY THE @!#! NOT?!?!?
The shell is 'supposed' to be run by a user that is allowed to run any
command he wants, and permission/trust issues are handled by the
login/authentication process that happens before you get to the s
For someone who apparently has no idea what he's talking about, you
sure say a lot.
On Tue, Feb 26, 2008 at 12:40 PM, Benjamin Smith
<[EMAIL PROTECTED]> wrote:
> You missed the point.
No, you missed it. You need the quotes *everywhere* that a variable
is referenced.
> In script2.sh, $1 only c
On Tue, Feb 26, 2008 at 11:22:55AM -0800, Benjamin Smith wrote:
> file: script1.sh
> #! /bin/bash
> script2.sh $1
There's your mistake. It should be
script2.sh "$1"
Otherwise $1 is evaluated and passed through as potentially multiple
parameters to script2.sh
For example:
$ cat x
#!/bin/
On Tue, Feb 26, 2008 at 12:40:06PM -0800, Benjamin Smith alleged:
> I'd like to have a informed discussion, which, apparently, you either aren't
> interested in, or aren't capable of.
*shrug* I thought we were having a discussion. I'll leave you to it and stay
out of your way.
--
Garrick Sta
On Tuesday 26 February 2008, Garrick Staples wrote:
> > I'm not asking for this. I'm only asking for the option to be able to
trust
> > that a parameter is... a parameter. EG:
> >
> > file: script1.sh
> > #! /bin/bash
> > script2.sh $1
> > exit 0;
> >
> > file: script2.sh
> > #! /bin/bash
Are you trying to pass all parameters from one script to another or
just the first one ($1). If it's the former, have you tried using
"$@"? For the latter, "$1" might work.
Alfred
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/
On Tue, Feb 26, 2008 at 11:22:55AM -0800, Benjamin Smith alleged:
> On Tuesday 26 February 2008, Les Mikesell wrote:
> > >
> > > WHY THE @!#! NOT?!?!?
> >
> > The shell is 'supposed' to be run by a user that is allowed to run any
> > command he wants, and permission/trust issues are handled by t
On Tuesday 26 February 2008, Les Mikesell wrote:
> >
> > WHY THE @!#! NOT?!?!?
>
> The shell is 'supposed' to be run by a user that is allowed to run any
> command he wants, and permission/trust issues are handled by the
> login/authentication process that happens before you get to the shell.
On Tue, Feb 26, 2008 at 12:45:41PM -0600, Les Mikesell alleged:
> Garrick Staples wrote:
>
> >>How many "homebrew" ISP or hosting administration scripts could be
> >>compromised by simply putting a file in your home directory called ";rm
> >>-rf /" ?
> >
> >It's not as bad as you think because
Garrick Staples wrote:
How many "homebrew" ISP or hosting administration scripts could be compromised
by simply putting a file in your home directory called ";rm -rf /" ?
It's not as bad as you think because of the order of operations.
In all cases, these perform exactly as a string should r
Benjamin Smith wrote:
On Tuesday 26 February 2008, Ralph Angenendt wrote:
There is no mechanism for escaping untrusted input?
Correct. At least there's no magic quoting function.
Ok. So I'm going to have to pull up my sleeves and do this with sed/awk pipes.
Got it. I'll quit looking for a si
On Tue, Feb 26, 2008 at 08:25:54AM -0800, Benjamin Smith alleged:
> On Tuesday 26 February 2008, Ralph Angenendt wrote:
> > > There is no mechanism for escaping untrusted input?
> >
> > Correct. At least there's no magic quoting function.
>
> Ok. So I'm going to have to pull up my sleeves and do
Benjamin Smith wrote:
On Tuesday 26 February 2008, Ralph Angenendt wrote:
There is no mechanism for escaping untrusted input?
Correct. At least there's no magic quoting function.
WHY THE @!#! NOT?!?!?
Bash is used, extensively in many cases, to deal with untrusted data. This can
include
On Tuesday 26 February 2008, Ralph Angenendt wrote:
> > There is no mechanism for escaping untrusted input?
>
> Correct. At least there's no magic quoting function.
Ok. So I'm going to have to pull up my sleeves and do this with sed/awk pipes.
Got it. I'll quit looking for a simply solution to t
Benjamin Smith wrote:
> On Tuesday 26 February 2008, Bob Beers wrote:
> > short answer: single quotes will handle all characters,
> except single
> quotes.
> >
> > long answer: man bash
> > the section called QUOTING may help you figure a solution.
>
> I've read the man page. It helps if I a
Benjamin Smith wrote:
> There is no mechanism for escaping untrusted input?
Correct. At least there's no magic quoting function.
Ralph
pgp3MLwLhKMwH.pgp
Description: PGP signature
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailm
On Tuesday 26 February 2008, Bob Beers wrote:
> short answer: single quotes will handle all characters, except single
quotes.
>
> long answer: man bash
> the section called QUOTING may help you figure a solution.
I've read the man page. It helps if I already know the input - I don't have a
p
On Tue, Feb 26, 2008 at 10:11 AM, Benjamin Smith <[EMAIL PROTECTED]>
wrote:
> In bash, given a string assignment as follows, how do I "add slashes"
> automagically, so that it can be safely passed to another program? Notice
> that the assignment contains spaces, single-quotes and double-quotes,
>
39 matches
Mail list logo
