Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
sudo chmod -R
21 views
Skip to first unread message
Király
Oct 28, 2012, 6:53:25 PM10/28/12
to
How do I run this:
sudo chmod -R g+rw /path/to/some/folder
and have it work only on nested files that end with the extension *.AVI?
I don't want to run the command on the whole thing.
--
K.
Te tetted e tettetett tettet? Te tettetett tettek tettetett tettese, te!
sudo chmod -R g+rw /path/to/some/folder
and have it work only on nested files that end with the extension *.AVI?
I don't want to run the command on the whole thing.
--
K.
Te tetted e tettetett tettet? Te tettetett tettek tettetett tettese, te!
Paul Sture
Oct 28, 2012, 7:34:01 PM10/28/12
to
In article <k6kd14$2lg$1...@dont-email.me>, m...@home.spamsucks.ca (Király)
wrote:
> How do I run this:
>
> sudo chmod -R g+rw /path/to/some/folder
>
> and have it work only on nested files that end with the extension *.AVI?
> I don't want to run the command on the whole thing.
This one should do the trick. I have tested it.
cd /path/to/some/folder
find . -name '*.AVI' -exec chmod g+rw '{}' \;
The single quotes around {} are for filenames containing spaces.
--
Paul Sture
wrote:
> How do I run this:
>
> sudo chmod -R g+rw /path/to/some/folder
>
> and have it work only on nested files that end with the extension *.AVI?
> I don't want to run the command on the whole thing.
cd /path/to/some/folder
find . -name '*.AVI' -exec chmod g+rw '{}' \;
The single quotes around {} are for filenames containing spaces.
--
Paul Sture
Paul Sture
Oct 28, 2012, 7:45:36 PM10/28/12
to
In article <nospam-FE54FB....@news.chingola.ch>,
I forgot. Add -v to see which files it modifies:
find . -name '*.AVI' -exec chmod -v g+rw '{}' \;
--
Paul Sture
find . -name '*.AVI' -exec chmod -v g+rw '{}' \;
--
Paul Sture
Király
Oct 28, 2012, 7:48:18 PM10/28/12
to
Paul Sture <nos...@sture.ch> wrote:
> This one should do the trick. I have tested it.
>
> cd /path/to/some/folder
> find . -name '*.AVI' -exec chmod g+rw '{}' \;
It did - thanks for the quick response!
> This one should do the trick. I have tested it.
>
> cd /path/to/some/folder
> find . -name '*.AVI' -exec chmod g+rw '{}' \;
Richard Kettlewell
Oct 29, 2012, 5:12:07 AM10/29/12
to
Paul Sture <nos...@sture.ch> writes:
> m...@home.spamsucks.ca (Király) wrote:
>> How do I run this:
>>
>> sudo chmod -R g+rw /path/to/some/folder
>>
>> and have it work only on nested files that end with the extension *.AVI?
>> I don't want to run the command on the whole thing.
>
> This one should do the trick. I have tested it.
>
> cd /path/to/some/folder
> find . -name '*.AVI' -exec chmod g+rw '{}' \;
>
> The single quotes around {} are for filenames containing spaces.
They aren’t necessary in that context; find doesn’t see them (just {})
> m...@home.spamsucks.ca (Király) wrote:
>> How do I run this:
>>
>> sudo chmod -R g+rw /path/to/some/folder
>>
>> and have it work only on nested files that end with the extension *.AVI?
>> I don't want to run the command on the whole thing.
>
> This one should do the trick. I have tested it.
>
> cd /path/to/some/folder
> find . -name '*.AVI' -exec chmod g+rw '{}' \;
>
> The single quotes around {} are for filenames containing spaces.
and it doesn’t use the shell when executing chmod.
--
http://www.greenend.org.uk/rjk/
Paul Sture
Oct 29, 2012, 10:22:19 AM10/29/12
to
Wes Groleau
Oct 30, 2012, 10:03:18 PM10/30/12
to
/Users/account/Application: file not found
Support/Thunderbird/something: file not found
--
Wes Groleau
Is it an on-line compliment to call someone a Net Wit ?
Richard Kettlewell
Oct 31, 2012, 6:11:30 AM10/31/12
to
quoting {} doesn’t make any difference to anything, except possibly the
level of wear on your keyboard.
--
http://www.greenend.org.uk/rjk/
Wes Groleau
Oct 31, 2012, 10:09:29 PM10/31/12
to
and
find <dir> <conditions> -exec <command> "{}" \;
_DO_ produce different results when some of the {} contain spaces.
Seen it with my own eyes. Took me quite a while to train myself to not
forget the quotes. (I developed my habits on systems where most users
were smart enough to not put spaces in filenames)
--
Wes Groleau
What kind of smiley is C:\ ?
Jolly Roger
Oct 31, 2012, 11:19:02 PM10/31/12
to
In article <k6slkq$qa$1...@dont-email.me>,
> >>> and it doesnšt use the shell when executing chmod.
> > quoting {} doesnšt make any difference to anything, except possibly the
--
Send responses to the relevant news group rather than email to me.
E-mail sent to this address may be devoured by my very hungry SPAM
filter. Due to Google's refusal to prevent spammers from posting
messages through their servers, I often ignore posts from Google
Groups. Use a real news client if you want me to see your posts.
JR
Wes Groleau <Grolea...@FreeShell.org> wrote:
> On 10-31-2012 06:11, Richard Kettlewell wrote:
> > Wes Groleau <Grolea...@FreeShell.org> writes:
> >
> >> On 10-29-2012 05:12, Richard Kettlewell wrote:
> >>> Paul Sture <nos...@sture.ch> writes:
> >
> >>>> This one should do the trick. I have tested it.
> >>>>
> >>>> cd /path/to/some/folder
> >>>> find . -name '*.AVI' -exec chmod g+rw '{}' \;
> >>>>
> >>>> The single quotes around {} are for filenames containing spaces.
> >>>
> >>> They arenšt necessary in that context; find doesnšt see them (just {})
> On 10-31-2012 06:11, Richard Kettlewell wrote:
> > Wes Groleau <Grolea...@FreeShell.org> writes:
> >
> >> On 10-29-2012 05:12, Richard Kettlewell wrote:
> >>> Paul Sture <nos...@sture.ch> writes:
> >
> >>>> This one should do the trick. I have tested it.
> >>>>
> >>>> cd /path/to/some/folder
> >>>> find . -name '*.AVI' -exec chmod g+rw '{}' \;
> >>>>
> >>>> The single quotes around {} are for filenames containing spaces.
> >>>
> >>> and it doesnšt use the shell when executing chmod.
> >>
> >> I _have_ received errors from filenames with spaces in find commands.
> >>
> >> /Users/account/Application: file not found
> >> Support/Thunderbird/something: file not found
> >
> > You probably used -exec without the ł{} ;˛ syntax. The fact is that
> >> I _have_ received errors from filenames with spaces in find commands.
> >>
> >> /Users/account/Application: file not found
> >> Support/Thunderbird/something: file not found
> >
> > quoting {} doesnšt make any difference to anything, except possibly the
> > level of wear on your keyboard.
>
> find <dir> <conditions> -exec <command> {} \;
> and
> find <dir> <conditions> -exec <command> "{}" \;
>
> _DO_ produce different results when some of the {} contain spaces.
>
> Seen it with my own eyes. Took me quite a while to train myself to not
> forget the quotes.
Yep - same here!
>
> find <dir> <conditions> -exec <command> {} \;
> and
> find <dir> <conditions> -exec <command> "{}" \;
>
> _DO_ produce different results when some of the {} contain spaces.
>
> Seen it with my own eyes. Took me quite a while to train myself to not
> forget the quotes.
--
Send responses to the relevant news group rather than email to me.
E-mail sent to this address may be devoured by my very hungry SPAM
filter. Due to Google's refusal to prevent spammers from posting
messages through their servers, I often ignore posts from Google
Groups. Use a real news client if you want me to see your posts.
JR
Barry Margolin
Nov 1, 2012, 12:31:24 AM11/1/12
to
> find <dir> <conditions> -exec <command> {} \;
> and
> find <dir> <conditions> -exec <command> "{}" \;
>
> _DO_ produce different results when some of the {} contain spaces.
>
> Seen it with my own eyes. Took me quite a while to train myself to not
> forget the quotes. (I developed my habits on systems where most users
> were smart enough to not put spaces in filenames)
That's totally impossible. The quotes are handled by the shell, and the
> and
> find <dir> <conditions> -exec <command> "{}" \;
>
> _DO_ produce different results when some of the {} contain spaces.
>
> Seen it with my own eyes. Took me quite a while to train myself to not
> forget the quotes. (I developed my habits on systems where most users
> were smart enough to not put spaces in filenames)
find command receives the same parameters in both cases.
Maybe you're thinking of something like this:
find ... -exec sh -c '<command> {}' \;
vs.
find ... -exec sh -c '<command> "{}"' \;
--
Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
Richard Kettlewell
Nov 1, 2012, 5:20:08 AM11/1/12
to
Wes Groleau <Grolea...@FreeShell.org> writes:
results. The shell simply does not work the way you think it does.
For example:
araminta$ find . -exec ls -dl {} \;
drwxrwxr-x 2 richard richard 4096 Nov 1 09:15 .
-rw-rw-r-- 1 richard richard 0 Nov 1 09:15 ./a file with spaces in the name
araminta$ find . -exec ls -dl "{}" \;
drwxrwxr-x 2 richard richard 4096 Nov 1 09:15 .
-rw-rw-r-- 1 richard richard 0 Nov 1 09:15 ./a file with spaces in the name
--
http://www.greenend.org.uk/rjk/
> Richard Kettlewell wrote:
>> You probably used -exec without the “{} ;” syntax. The fact is that
>> quoting {} doesn’t make any difference to anything, except possibly the
>> level of wear on your keyboard.
>
> find <dir> <conditions> -exec <command> {} \;
> and
> find <dir> <conditions> -exec <command> "{}" \;
>
> _DO_ produce different results when some of the {} contain spaces.
>
> Seen it with my own eyes. Took me quite a while to train myself to
> not forget the quotes. (I developed my habits on systems where most
> users were smart enough to not put spaces in filenames)
You are misremembering. Those two commands will produce identical
>> You probably used -exec without the “{} ;” syntax. The fact is that
>> quoting {} doesn’t make any difference to anything, except possibly the
>> level of wear on your keyboard.
>
> find <dir> <conditions> -exec <command> {} \;
> and
> find <dir> <conditions> -exec <command> "{}" \;
>
> _DO_ produce different results when some of the {} contain spaces.
>
> Seen it with my own eyes. Took me quite a while to train myself to
> not forget the quotes. (I developed my habits on systems where most
> users were smart enough to not put spaces in filenames)
results. The shell simply does not work the way you think it does.
For example:
araminta$ find . -exec ls -dl {} \;
drwxrwxr-x 2 richard richard 4096 Nov 1 09:15 .
-rw-rw-r-- 1 richard richard 0 Nov 1 09:15 ./a file with spaces in the name
araminta$ find . -exec ls -dl "{}" \;
drwxrwxr-x 2 richard richard 4096 Nov 1 09:15 .
-rw-rw-r-- 1 richard richard 0 Nov 1 09:15 ./a file with spaces in the name
--
http://www.greenend.org.uk/rjk/
Mark Geary
Nov 1, 2012, 3:24:25 PM11/1/12
to
In article <k6slkq$qa$1...@dont-email.me>, Wes Groleau <non...@your.biz> wrote:
>
> find <dir> <conditions> -exec <command> {} \;
> and
> find <dir> <conditions> -exec <command> "{}" \;
>
> _DO_ produce different results when some of the {} contain spaces.
>
> Seen it with my own eyes. Took me quite a while to train myself to not
> forget the quotes. (I developed my habits on systems where most users
> were smart enough to not put spaces in filenames)
I prefer xargs:
>
> find <dir> <conditions> -exec <command> {} \;
> and
> find <dir> <conditions> -exec <command> "{}" \;
>
> _DO_ produce different results when some of the {} contain spaces.
>
> Seen it with my own eyes. Took me quite a while to train myself to not
> forget the quotes. (I developed my habits on systems where most users
> were smart enough to not put spaces in filenames)
find <dir> <conditions> -print0 | xargs -0 <command>
The "-print0" and "-0" aren't necessary if none of the pathnames will
have spaces or other odd characters.
Mark Geary
--
Don't forget to stop and eat the roses.
Wes Groleau
Nov 1, 2012, 7:24:42 PM11/1/12
to
On 11-01-2012 00:31, Barry Margolin wrote:
> That's totally impossible. The quotes are handled by the shell, and the
> find command receives the same parameters in both cases.
It's just incredible how many impossible things I've done.
> That's totally impossible. The quotes are handled by the shell, and the
> find command receives the same parameters in both cases.
Wish I could figure a way to market it.
Barry Margolin
Nov 1, 2012, 9:23:49 PM11/1/12
to
In article <k6v0bs$lur$1...@dont-email.me>,
Wes Groleau <Grolea...@FreeShell.org> wrote:
> On 11-01-2012 00:31, Barry Margolin wrote:
> > That's totally impossible. The quotes are handled by the shell, and the
> > find command receives the same parameters in both cases.
>
> It's just incredible how many impossible things I've done.
>
> Wish I could figure a way to market it.
Did you do six impossible things before breakfast?
> On 11-01-2012 00:31, Barry Margolin wrote:
> > That's totally impossible. The quotes are handled by the shell, and the
> > find command receives the same parameters in both cases.
>
> It's just incredible how many impossible things I've done.
>
> Wish I could figure a way to market it.
Barry Margolin
Nov 1, 2012, 9:44:30 PM11/1/12
to
In article <5092cc69$0$27109$c3e8da3$92d0...@news.astraweb.com>,
I used to prefer xargs, but I've switched to -exec since I learned about
using + at the end instead of \;. That tells find to put all the
filenames in one command, just like xargs does.
using + at the end instead of \;. That tells find to put all the
filenames in one command, just like xargs does.
Wes Groleau
Nov 2, 2012, 12:12:28 AM11/2/12
to
On 11-01-2012 19:24, Wes Groleau wrote:
> On 11-01-2012 00:31, Barry Margolin wrote:
>> That's totally impossible. The quotes are handled by the shell, and the
>> find command receives the same parameters in both cases.
>
> It's just incredible how many impossible things I've done.
>
> Wish I could figure a way to market it.
And I wouldn't have known they were impossible if this newsgroup didn't
> On 11-01-2012 00:31, Barry Margolin wrote:
>> That's totally impossible. The quotes are handled by the shell, and the
>> find command receives the same parameters in both cases.
>
> It's just incredible how many impossible things I've done.
>
> Wish I could figure a way to market it.
tell me.
Mark Geary
Nov 2, 2012, 9:45:25 AM11/2/12
to
> find <dir> <conditions> -exec <command> {} \;
> and
> find <dir> <conditions> -exec <command> "{}" \;
>
> _DO_ produce different results when some of the {} contain spaces.
>
> Seen it with my own eyes. Took me quite a while to train myself to not
> forget the quotes. (I developed my habits on systems where most users
> were smart enough to not put spaces in filenames)
Can you give some examples where it matters? I tried it on Mac OS 10.6
> and
> find <dir> <conditions> -exec <command> "{}" \;
>
> _DO_ produce different results when some of the {} contain spaces.
>
> Seen it with my own eyes. Took me quite a while to train myself to not
> forget the quotes. (I developed my habits on systems where most users
> were smart enough to not put spaces in filenames)
and didn't see any difference:
~/zz user$ ls -l
total 0
-rw-r--r-- 1 user staff 0 Nov 2 09:19 a
-rw-r--r-- 1 user staff 0 Nov 2 09:34 b'c
-rw-r--r-- 1 user staff 0 Nov 2 09:19 c d
-rw-r--r-- 1 user staff 0 Nov 2 09:19 d e f
-rw-r--r-- 1 user staff 0 Nov 2 09:35 e{} f [\] g
-rw-r--r-- 1 user staff 0 Nov 2 09:34 f"g
~/zz user$ find . -type f -exec echo "{}" \;
./a
./b'c
./c d
./d e f
./e{} f [\] g
./f"g
~/zz user$ find . -type f -exec echo '"{}"' \;
"./a"
"./b'c"
"./c d"
"./d e f"
"./e{} f [\] g"
"./f"g"
Mark Geary
Nov 2, 2012, 9:51:35 AM11/2/12
to
Oops, wrong cut and paste. Correct reply below.
Message has been deleted
Richard Kettlewell
Nov 2, 2012, 11:00:21 AM11/2/12
to
Lewis <g.k...@gmail.com.dontsendmecopies> writes:
> with ls, for example.
>
> find ~/Library/ -type d -maxdepth 1 -exec ls -lsd {} \;
>
> However, I have certainly run into instances were I had to use "{}".
I'm afraid you are misremembering. The same string is passed to find in
both cases, and its behavior is consequently the same. This is not a
matter of opinion, speculation or guesswork; it is a fact about how the
shell works, which can be confirmed by inspection, by reading the manual
or by experiment.
--
http://www.greenend.org.uk/rjk/
> Barry Margolin <bar...@alum.mit.edu> wrote:
>> Wes Groleau <Grolea...@FreeShell.org> wrote:
>>> find <dir> <conditions> -exec <command> {} \;
>>> and
>>> find <dir> <conditions> -exec <command> "{}" \;
>>>
>>> _DO_ produce different results when some of the {} contain spaces.
>>>
>>> Seen it with my own eyes. Took me quite a while to train myself to not
>>> forget the quotes. (I developed my habits on systems where most users
>>> were smart enough to not put spaces in filenames)
>
>> That's totally impossible. The quotes are handled by the shell, and the
>> find command receives the same parameters in both cases.
>
> Depending on what the exec command actually is, this can work. It works
>> Wes Groleau <Grolea...@FreeShell.org> wrote:
>>> find <dir> <conditions> -exec <command> {} \;
>>> and
>>> find <dir> <conditions> -exec <command> "{}" \;
>>>
>>> _DO_ produce different results when some of the {} contain spaces.
>>>
>>> Seen it with my own eyes. Took me quite a while to train myself to not
>>> forget the quotes. (I developed my habits on systems where most users
>>> were smart enough to not put spaces in filenames)
>
>> That's totally impossible. The quotes are handled by the shell, and the
>> find command receives the same parameters in both cases.
>
> with ls, for example.
>
> find ~/Library/ -type d -maxdepth 1 -exec ls -lsd {} \;
>
> However, I have certainly run into instances were I had to use "{}".
I'm afraid you are misremembering. The same string is passed to find in
both cases, and its behavior is consequently the same. This is not a
matter of opinion, speculation or guesswork; it is a fact about how the
shell works, which can be confirmed by inspection, by reading the manual
or by experiment.
--
http://www.greenend.org.uk/rjk/
Barry Margolin
Nov 2, 2012, 11:47:12 AM11/2/12
to
In article <slrnk97mct....@mbp55.local>,
Lewis <g.k...@gmail.com.dontsendmecopies> wrote:
> In message <barmar-5BE125....@news.eternal-september.org>
time arguments are passed to find they are exactly the same.
I challenge you to come up with an example.
Lewis <g.k...@gmail.com.dontsendmecopies> wrote:
> In message <barmar-5BE125....@news.eternal-september.org>
> Barry Margolin <bar...@alum.mit.edu> wrote:
> > In article <k6slkq$qa$1...@dont-email.me>,
> > Wes Groleau <Grolea...@FreeShell.org> wrote:
>
> >> find <dir> <conditions> -exec <command> {} \;
> >> and
> >> find <dir> <conditions> -exec <command> "{}" \;
> >>
> >> _DO_ produce different results when some of the {} contain spaces.
> >>
> >> Seen it with my own eyes. Took me quite a while to train myself to not
> >> forget the quotes. (I developed my habits on systems where most users
> >> were smart enough to not put spaces in filenames)
>
> > That's totally impossible. The quotes are handled by the shell, and the
> > find command receives the same parameters in both cases.
>
> > In article <k6slkq$qa$1...@dont-email.me>,
> > Wes Groleau <Grolea...@FreeShell.org> wrote:
>
> >> find <dir> <conditions> -exec <command> {} \;
> >> and
> >> find <dir> <conditions> -exec <command> "{}" \;
> >>
> >> _DO_ produce different results when some of the {} contain spaces.
> >>
> >> Seen it with my own eyes. Took me quite a while to train myself to not
> >> forget the quotes. (I developed my habits on systems where most users
> >> were smart enough to not put spaces in filenames)
>
> > That's totally impossible. The quotes are handled by the shell, and the
> > find command receives the same parameters in both cases.
>
> Depending on what the exec command actually is, this can work. It works
> with ls, for example.
>
> find ~/Library/ -type d -maxdepth 1 -exec ls -lsd {} \;
>
> However, I have certainly run into instances were I had to use "{}".
I stilll say it's impossible. The shell processes the quotes, so by the
> with ls, for example.
>
> find ~/Library/ -type d -maxdepth 1 -exec ls -lsd {} \;
>
> However, I have certainly run into instances were I had to use "{}".
time arguments are passed to find they are exactly the same.
I challenge you to come up with an example.
Jolly Roger
Nov 2, 2012, 11:55:39 AM11/2/12
to
In article <slrnk97mct....@mbp55.local>,
Lewis <g.k...@gmail.com.dontsendmecopies> wrote:
> In message <barmar-5BE125....@news.eternal-september.org>
> Barry Margolin <bar...@alum.mit.edu> wrote:
Lewis <g.k...@gmail.com.dontsendmecopies> wrote:
> In message <barmar-5BE125....@news.eternal-september.org>
> Barry Margolin <bar...@alum.mit.edu> wrote:
> > In article <k6slkq$qa$1...@dont-email.me>,
> > Wes Groleau <Grolea...@FreeShell.org> wrote:
>
> >> find <dir> <conditions> -exec <command> {} \;
> >> and
> >> find <dir> <conditions> -exec <command> "{}" \;
> >>
> >> _DO_ produce different results when some of the {} contain spaces.
> >>
> >> Seen it with my own eyes. Took me quite a while to train myself to not
> >> forget the quotes. (I developed my habits on systems where most users
> >> were smart enough to not put spaces in filenames)
>
> > That's totally impossible. The quotes are handled by the shell, and the
> > find command receives the same parameters in both cases.
>
> > Wes Groleau <Grolea...@FreeShell.org> wrote:
>
> >> find <dir> <conditions> -exec <command> {} \;
> >> and
> >> find <dir> <conditions> -exec <command> "{}" \;
> >>
> >> _DO_ produce different results when some of the {} contain spaces.
> >>
> >> Seen it with my own eyes. Took me quite a while to train myself to not
> >> forget the quotes. (I developed my habits on systems where most users
> >> were smart enough to not put spaces in filenames)
>
> > That's totally impossible. The quotes are handled by the shell, and the
> > find command receives the same parameters in both cases.
>
> Depending on what the exec command actually is, this can work. It works
> with ls, for example.
>
> find ~/Library/ -type d -maxdepth 1 -exec ls -lsd {} \;
>
> However, I have certainly run into instances were I had to use "{}".
As have I. Making a blanket statement that it's impossible seems like a
> with ls, for example.
>
> find ~/Library/ -type d -maxdepth 1 -exec ls -lsd {} \;
>
> However, I have certainly run into instances were I had to use "{}".
reach to me.
Jolly Roger
Nov 2, 2012, 11:59:23 AM11/2/12
to
In article <5093cfe7$0$27173$c3e8da3$92d0...@news.astraweb.com>,
details, other than that adding quotes around {} fixed the issue. Sorry
I can't be more specific. It's quite possible it was required in an
older version of Mac OS X at some point, under certain circumstances. It
bit me once, and from then on I trained myself to use quotes around the
{}. Now that this discussion is happening, I haven't yet been able to
reproduce it. Perhaps it's time to change my habits. : )
ge...@eris.prismnet.com (Mark Geary) wrote:
> Oops, wrong cut and paste. Correct reply below.
>
> In article <k6slkq$qa$1...@dont-email.me>, Wes Groleau <non...@your.biz> wrote:
>
> > find <dir> <conditions> -exec <command> {} \;
> > and
> > find <dir> <conditions> -exec <command> "{}" \;
> >
> > _DO_ produce different results when some of the {} contain spaces.
> >
> > Seen it with my own eyes. Took me quite a while to train myself to not
> > forget the quotes. (I developed my habits on systems where most users
> > were smart enough to not put spaces in filenames)
>
> Can you give some examples where it matters? I tried it on Mac OS 10.6
> and didn't see any difference
Frankly, it's been so long since I;ve seen it, I don;t recall the
> Oops, wrong cut and paste. Correct reply below.
>
> In article <k6slkq$qa$1...@dont-email.me>, Wes Groleau <non...@your.biz> wrote:
>
> > find <dir> <conditions> -exec <command> {} \;
> > and
> > find <dir> <conditions> -exec <command> "{}" \;
> >
> > _DO_ produce different results when some of the {} contain spaces.
> >
> > Seen it with my own eyes. Took me quite a while to train myself to not
> > forget the quotes. (I developed my habits on systems where most users
> > were smart enough to not put spaces in filenames)
>
> Can you give some examples where it matters? I tried it on Mac OS 10.6
> and didn't see any difference
details, other than that adding quotes around {} fixed the issue. Sorry
I can't be more specific. It's quite possible it was required in an
older version of Mac OS X at some point, under certain circumstances. It
bit me once, and from then on I trained myself to use quotes around the
{}. Now that this discussion is happening, I haven't yet been able to
reproduce it. Perhaps it's time to change my habits. : )
Barry Margolin
Nov 2, 2012, 2:37:37 PM11/2/12
to
In article <jollyroger-E7DEE...@news.individual.net>,
no way that putting quotes around the {} could make any difference to
the operation of the find command. When you quote an argument to a
program, the quotes are not visible to the program itself. This is how
Unix shells have worked for ages, probably since Day 1.
It's almost certainly the case that when you added quotes around {} you
also changed something else, perhaps without realizing it. Maybe you
made a typo the first time, and didn't repeat it in the version with the
quotes. You didn't realize you made some other change, so assumed that
quoting was the fix, and have been laboring under this misunderstanding
ever since.
But correlation does not always imply causation, and engineering is
about knowing HOW things work. If you understand how shells parse the
command line, and how they then run the program, you'll realize that
this couldn't have been the actual fix.
Jolly Roger <jolly...@pobox.com> wrote:
> In article <5093cfe7$0$27173$c3e8da3$92d0...@news.astraweb.com>,
> ge...@eris.prismnet.com (Mark Geary) wrote:
>
> > Oops, wrong cut and paste. Correct reply below.
> >
> > In article <k6slkq$qa$1...@dont-email.me>, Wes Groleau <non...@your.biz>
> > wrote:
> >
> > > find <dir> <conditions> -exec <command> {} \;
> > > and
> > > find <dir> <conditions> -exec <command> "{}" \;
> > >
> > > _DO_ produce different results when some of the {} contain spaces.
> > >
> > > Seen it with my own eyes. Took me quite a while to train myself to not
> > > forget the quotes. (I developed my habits on systems where most users
> > > were smart enough to not put spaces in filenames)
> >
> > Can you give some examples where it matters? I tried it on Mac OS 10.6
> > and didn't see any difference
>
> Frankly, it's been so long since I;ve seen it, I don;t recall the
> details, other than that adding quotes around {} fixed the issue. Sorry
> I can't be more specific. It's quite possible it was required in an
> older version of Mac OS X at some point, under certain circumstances. It
> bit me once, and from then on I trained myself to use quotes around the
> {}. Now that this discussion is happening, I haven't yet been able to
> reproduce it. Perhaps it's time to change my habits. : )
I don't care if it was in a version of Unix 20 years old, there's simply
> In article <5093cfe7$0$27173$c3e8da3$92d0...@news.astraweb.com>,
> ge...@eris.prismnet.com (Mark Geary) wrote:
>
> > Oops, wrong cut and paste. Correct reply below.
> >
> > In article <k6slkq$qa$1...@dont-email.me>, Wes Groleau <non...@your.biz>
> > wrote:
> >
> > > find <dir> <conditions> -exec <command> {} \;
> > > and
> > > find <dir> <conditions> -exec <command> "{}" \;
> > >
> > > _DO_ produce different results when some of the {} contain spaces.
> > >
> > > Seen it with my own eyes. Took me quite a while to train myself to not
> > > forget the quotes. (I developed my habits on systems where most users
> > > were smart enough to not put spaces in filenames)
> >
> > Can you give some examples where it matters? I tried it on Mac OS 10.6
> > and didn't see any difference
>
> Frankly, it's been so long since I;ve seen it, I don;t recall the
> details, other than that adding quotes around {} fixed the issue. Sorry
> I can't be more specific. It's quite possible it was required in an
> older version of Mac OS X at some point, under certain circumstances. It
> bit me once, and from then on I trained myself to use quotes around the
> {}. Now that this discussion is happening, I haven't yet been able to
> reproduce it. Perhaps it's time to change my habits. : )
no way that putting quotes around the {} could make any difference to
the operation of the find command. When you quote an argument to a
program, the quotes are not visible to the program itself. This is how
Unix shells have worked for ages, probably since Day 1.
It's almost certainly the case that when you added quotes around {} you
also changed something else, perhaps without realizing it. Maybe you
made a typo the first time, and didn't repeat it in the version with the
quotes. You didn't realize you made some other change, so assumed that
quoting was the fix, and have been laboring under this misunderstanding
ever since.
But correlation does not always imply causation, and engineering is
about knowing HOW things work. If you understand how shells parse the
command line, and how they then run the program, you'll realize that
this couldn't have been the actual fix.
Paul Sture
Nov 2, 2012, 2:46:28 PM11/2/12
to
> In article <5093cfe7$0$27173$c3e8da3$92d0...@news.astraweb.com>,
> ge...@eris.prismnet.com (Mark Geary) wrote:
>
> > Oops, wrong cut and paste. Correct reply below.
> >
> > In article <k6slkq$qa$1...@dont-email.me>, Wes Groleau <non...@your.biz>
> > wrote:
> >
> > > find <dir> <conditions> -exec <command> {} \;
> > > and
> > > find <dir> <conditions> -exec <command> "{}" \;
> > >
> > > _DO_ produce different results when some of the {} contain spaces.
> > >
> > > Seen it with my own eyes. Took me quite a while to train myself to not
> > > forget the quotes. (I developed my habits on systems where most users
> > > were smart enough to not put spaces in filenames)
> >
> > Can you give some examples where it matters? I tried it on Mac OS 10.6
> > and didn't see any difference
>
> Frankly, it's been so long since I;ve seen it, I don;t recall the
> details, other than that adding quotes around {} fixed the issue. Sorry
> I can't be more specific. It's quite possible it was required in an
> older version of Mac OS X at some point, under certain circumstances. It
> bit me once, and from then on I trained myself to use quotes around the
> {}. Now that this discussion is happening, I haven't yet been able to
> reproduce it. Perhaps it's time to change my habits. : )
Same here. Sometime this weekend I will try to have a look on the
> ge...@eris.prismnet.com (Mark Geary) wrote:
>
> > Oops, wrong cut and paste. Correct reply below.
> >
> > In article <k6slkq$qa$1...@dont-email.me>, Wes Groleau <non...@your.biz>
> > wrote:
> >
> > > find <dir> <conditions> -exec <command> {} \;
> > > and
> > > find <dir> <conditions> -exec <command> "{}" \;
> > >
> > > _DO_ produce different results when some of the {} contain spaces.
> > >
> > > Seen it with my own eyes. Took me quite a while to train myself to not
> > > forget the quotes. (I developed my habits on systems where most users
> > > were smart enough to not put spaces in filenames)
> >
> > Can you give some examples where it matters? I tried it on Mac OS 10.6
> > and didn't see any difference
>
> Frankly, it's been so long since I;ve seen it, I don;t recall the
> details, other than that adding quotes around {} fixed the issue. Sorry
> I can't be more specific. It's quite possible it was required in an
> older version of Mac OS X at some point, under certain circumstances. It
> bit me once, and from then on I trained myself to use quotes around the
> {}. Now that this discussion is happening, I haven't yet been able to
> reproduce it. Perhaps it's time to change my habits. : )
non-OS X systems I have here.
--
Paul Sture
Paul Sture
Nov 2, 2012, 3:00:00 PM11/2/12
to
In article <k6vh7c$81m$2...@dont-email.me>,
when creating accounts? 10.1 used tcsh, and my work servers at that
time csh was in use.
As a follow up to that, is everyone talking about the version of find
that comes with OS X, or other *nix distributions?
--
Paul Sture
Wes Groleau <Grolea...@FreeShell.org> wrote:
> On 11-01-2012 19:24, Wes Groleau wrote:
> > On 11-01-2012 00:31, Barry Margolin wrote:
> >> That's totally impossible. The quotes are handled by the shell, and the
> >> find command receives the same parameters in both cases.
> >
> > It's just incredible how many impossible things I've done.
> >
> > Wish I could figure a way to market it.
>
> And I wouldn't have known they were impossible if this newsgroup didn't
> tell me.
Which version of OS X was it that introduced bash as the default shell
> On 11-01-2012 19:24, Wes Groleau wrote:
> > On 11-01-2012 00:31, Barry Margolin wrote:
> >> That's totally impossible. The quotes are handled by the shell, and the
> >> find command receives the same parameters in both cases.
> >
> > It's just incredible how many impossible things I've done.
> >
> > Wish I could figure a way to market it.
>
> And I wouldn't have known they were impossible if this newsgroup didn't
> tell me.
when creating accounts? 10.1 used tcsh, and my work servers at that
time csh was in use.
As a follow up to that, is everyone talking about the version of find
that comes with OS X, or other *nix distributions?
--
Paul Sture
Jolly Roger
Nov 2, 2012, 4:10:54 PM11/2/12
to
In article <barmar-D0E59D....@news.eternal-september.org>,
Sorry, but being a veteran software developer, I know very well that
just because something should work a certain way, there is no guarantee
that a bug or unexpected condition won't change that behavior. It'll
take more than just your assurance for me to just swallow your blanket
statement that adding quotes couldn't possibly have fixed the problem.
just because something should work a certain way, there is no guarantee
that a bug or unexpected condition won't change that behavior. It'll
take more than just your assurance for me to just swallow your blanket
statement that adding quotes couldn't possibly have fixed the problem.
nospam
Nov 2, 2012, 5:57:39 PM11/2/12
to
In article <barmar-D0E59D....@news.eternal-september.org>,
Barry Margolin <bar...@alum.mit.edu> wrote:
Barry Margolin <bar...@alum.mit.edu> wrote:
Paul Sture
Nov 2, 2012, 5:46:18 PM11/2/12
to
In article <jollyroger-61CFF...@news.individual.net>,
way to insert double quotes into a string using that CLI was to double
them up e.g.
string = "some text ""quoted substring"" more text"
Yet with one particular utility which talked to a foreign system (via
FTP or NFS IIRC), you needed to triple those quotes. We never worked
out why, but were happy that it worked.
--
Paul Sture
Jolly Roger <jolly...@pobox.com> wrote:
> In article <barmar-D0E59D....@news.eternal-september.org>,
> Barry Margolin <bar...@alum.mit.edu> wrote:
>
> > But correlation does not always imply causation, and engineering is
> > about knowing HOW things work. If you understand how shells parse the
> > command line, and how they then run the program, you'll realize that
> > this couldn't have been the actual fix.
>
> Sorry, but being a veteran software developer, I know very well that
> just because something should work a certain way, there is no guarantee
> that a bug or unexpected condition won't change that behavior. It'll
> take more than just your assurance for me to just swallow your blanket
> statement that adding quotes couldn't possibly have fixed the problem.
That reminds me of something I came across in VMS many years ago. One
> In article <barmar-D0E59D....@news.eternal-september.org>,
> Barry Margolin <bar...@alum.mit.edu> wrote:
>
> > But correlation does not always imply causation, and engineering is
> > about knowing HOW things work. If you understand how shells parse the
> > command line, and how they then run the program, you'll realize that
> > this couldn't have been the actual fix.
>
> Sorry, but being a veteran software developer, I know very well that
> just because something should work a certain way, there is no guarantee
> that a bug or unexpected condition won't change that behavior. It'll
> take more than just your assurance for me to just swallow your blanket
> statement that adding quotes couldn't possibly have fixed the problem.
way to insert double quotes into a string using that CLI was to double
them up e.g.
string = "some text ""quoted substring"" more text"
Yet with one particular utility which talked to a foreign system (via
FTP or NFS IIRC), you needed to triple those quotes. We never worked
out why, but were happy that it worked.
--
Paul Sture
nospam
Nov 2, 2012, 6:00:11 PM11/2/12
to
Barry Margolin
Nov 2, 2012, 6:05:56 PM11/2/12
to
In article <jollyroger-61CFF...@news.individual.net>,
I've also been programming for about 35 years, and I realize there are
bugs. But this one seems like a very unlikely one to slip by -- someone
would have noticed. By the time Macs started using Unix, this was very
mature software. And I doubt this part of the shell required any
modifications by Apple, so there wouldn't have been an opportunity to
add such a bug.
Someone mentioned that it might have been when the default shell on Macs
was csh. csh's parser is more ad hoc, and has had lots of bugs. Although
I think Macs always used tcsh, which resolved many of those problems.
But I wouldn't find it hard to believe that an old version of tcsh had a
problem where it did the wrong thing with {} -- maybe it reported it as
an error. But it would have to be really old -- the version on my Snow
Leopard system says it's from 2007. However, I was using tcsh as my
default shell on other Unix systems in the 90's, and I don't recall any
problem with find back then. Again, this is a part of the software that
is unlikely to differ from one OS to the other.
bugs. But this one seems like a very unlikely one to slip by -- someone
would have noticed. By the time Macs started using Unix, this was very
mature software. And I doubt this part of the shell required any
modifications by Apple, so there wouldn't have been an opportunity to
add such a bug.
Someone mentioned that it might have been when the default shell on Macs
was csh. csh's parser is more ad hoc, and has had lots of bugs. Although
I think Macs always used tcsh, which resolved many of those problems.
But I wouldn't find it hard to believe that an old version of tcsh had a
problem where it did the wrong thing with {} -- maybe it reported it as
an error. But it would have to be really old -- the version on my Snow
Leopard system says it's from 2007. However, I was using tcsh as my
default shell on other Unix systems in the 90's, and I don't recall any
problem with find back then. Again, this is a part of the software that
is unlikely to differ from one OS to the other.
Barry Margolin
Nov 2, 2012, 6:20:34 PM11/2/12
to
In article <nospam-3D7EBD....@news.chingola.ch>,
arguments of a program. On Unix, the challenge often arises when you're
doing:
ssh hostname <command>
If the command you're trying to run contains quoted strings and
variables, figuring out all the quoting and escaping can be difficult.
I've nearly driven myself crazy trying to run awk commands like this,
since you need to ensure that $ is NOT expanded either locally or in the
remote shell, because it has to get into awk's literal argument.
I used to use Multics, which also use quote doubling. Its equivalent to
Unix's "if" and "for" commands required putting the body as a single
quoted argument, so if you had nested conditionals and loops you could
easily end up with a sequence of 8 or 16 quotes (actually, this was only
necessary for interactive commands -- it had a separate mechanism for
running scripts that added its own directives for flow control).
Paul Sture <nos...@sture.ch> wrote:
> That reminds me of something I came across in VMS many years ago. One
> way to insert double quotes into a string using that CLI was to double
> them up e.g.
>
> string = "some text ""quoted substring"" more text"
>
> Yet with one particular utility which talked to a foreign system (via
> FTP or NFS IIRC), you needed to triple those quotes. We never worked
> out why, but were happy that it worked.
Things do get tricky when you need to get a quoted substring into the
> That reminds me of something I came across in VMS many years ago. One
> way to insert double quotes into a string using that CLI was to double
> them up e.g.
>
> string = "some text ""quoted substring"" more text"
>
> Yet with one particular utility which talked to a foreign system (via
> FTP or NFS IIRC), you needed to triple those quotes. We never worked
> out why, but were happy that it worked.
arguments of a program. On Unix, the challenge often arises when you're
doing:
ssh hostname <command>
If the command you're trying to run contains quoted strings and
variables, figuring out all the quoting and escaping can be difficult.
I've nearly driven myself crazy trying to run awk commands like this,
since you need to ensure that $ is NOT expanded either locally or in the
remote shell, because it has to get into awk's literal argument.
I used to use Multics, which also use quote doubling. Its equivalent to
Unix's "if" and "for" commands required putting the body as a single
quoted argument, so if you had nested conditionals and loops you could
easily end up with a sequence of 8 or 16 quotes (actually, this was only
necessary for interactive commands -- it had a separate mechanism for
running scripts that added its own directives for flow control).
Message has been deleted
nospam
Nov 2, 2012, 6:37:02 PM11/2/12
to
In article <barmar-D71115....@news.eternal-september.org>,
10.3 unless upgrading from an earlier system and then it stayed tcsh.
csh, ksh and zsh were available, but you had to explicitly set it.
Barry Margolin <bar...@alum.mit.edu> wrote:
> Someone mentioned that it might have been when the default shell on Macs
> was csh. csh's parser is more ad hoc, and has had lots of bugs. Although
> I think Macs always used tcsh, which resolved many of those problems.
the default shell on os x was tcsh through 10.2. it switched to bash in
> Someone mentioned that it might have been when the default shell on Macs
> was csh. csh's parser is more ad hoc, and has had lots of bugs. Although
> I think Macs always used tcsh, which resolved many of those problems.
10.3 unless upgrading from an earlier system and then it stayed tcsh.
csh, ksh and zsh were available, but you had to explicitly set it.
Message has been deleted
nospam
Nov 2, 2012, 6:39:46 PM11/2/12
to
In article <slrnk98ipo....@mbp55.local>, Lewis
> am not positive.
*well* before that. it changed in 10.3.
<g.k...@gmail.com.dontsendmecopies> wrote:
> > Which version of OS X was it that introduced bash as the default shell
> > when creating accounts? 10.1 used tcsh, and my work servers at that
> > time csh was in use.
>
> I think the change was in 10.5, but I'd changed well before that, so I
> > Which version of OS X was it that introduced bash as the default shell
> > when creating accounts? 10.1 used tcsh, and my work servers at that
> > time csh was in use.
>
> am not positive.
*well* before that. it changed in 10.3.
Richard Kettlewell
Nov 2, 2012, 6:42:53 PM11/2/12
to
Lewis <g.k...@gmail.com.dontsendmecopies> writes:
> I'm thinking the last time I hit it was when I was using Handbrake to
> process an entire folder of videos.
>
> Yeah, here is the command I had to use:
>
> find . -name "*.mkv" -exec handbrake -i "{}" -o "{}.m4v" -Z "Apple TV 2" \;
>
> Doesn't work without the "" marks
The quotes around the "*.mkv" and the "Apple TV 2" are necessary; those
around {} and {}.m4v are not.
--
http://www.greenend.org.uk/rjk/
> I'm thinking the last time I hit it was when I was using Handbrake to
> process an entire folder of videos.
>
> Yeah, here is the command I had to use:
>
> find . -name "*.mkv" -exec handbrake -i "{}" -o "{}.m4v" -Z "Apple TV 2" \;
>
> Doesn't work without the "" marks
The quotes around the "*.mkv" and the "Apple TV 2" are necessary; those
around {} and {}.m4v are not.
--
http://www.greenend.org.uk/rjk/
Jolly Roger
Nov 2, 2012, 6:43:55 PM11/2/12
to
In article <barmar-D71115....@news.eternal-september.org>,
Yeah. I hear you. Don't get me wrong - I do respect your opinion. I'm
just not so sure that Apple hasn't made their own modifications to the
shells in various versions of Mac OS X. They've certainly done it for
plenty of other command-line tools in Mac OS X that ave interaction with
the shell. Likewise, it doesn't seem out of the realm of possibility to
me that a bug caused this issue that has since been fixed. I guess
without having a reproducible case handy, the discussion is moot, since
there is no proof either way. Like I said, though, I do think it may be
time for me to shed that old habit.
just not so sure that Apple hasn't made their own modifications to the
shells in various versions of Mac OS X. They've certainly done it for
plenty of other command-line tools in Mac OS X that ave interaction with
the shell. Likewise, it doesn't seem out of the realm of possibility to
me that a bug caused this issue that has since been fixed. I guess
without having a reproducible case handy, the discussion is moot, since
there is no proof either way. Like I said, though, I do think it may be
time for me to shed that old habit.
Barry Margolin
Nov 2, 2012, 6:45:29 PM11/2/12
to
In article <slrnk98ijl....@mbp55.local>,
Lewis <g.k...@gmail.com.dontsendmecopies> wrote:
> In message <jollyroger-E7DEE...@news.individual.net>
ones around *.mkv. That's because the shell expands wildcards unless you
quote them, and find needs to receive the wildcard as a literal,
unexpanded argument (so that it can check whether files in
subdirectories match the pattern).
So my suspicion is that you first tried:
find . -name *.mkv -exec handbrake -i {} -o {}.m4v -Z "Apple TV 2" \;
and it didn't work. Then you added quotes in all 3 places, found that
it worked, and didn't bother to figure out just which quotes were really
needed.
Sometimes you can get away without that quoting -- if there are no
matches for the wildcard, it's left intact (unless you set a shell
option to make it report an error, but it's not the default). So if all
the matching files are in subdirectories, you can type *.mkv without the
quotes.
Lewis <g.k...@gmail.com.dontsendmecopies> wrote:
> In message <jollyroger-E7DEE...@news.individual.net>
> Jolly Roger <jolly...@pobox.com> wrote:
> > In article <5093cfe7$0$27173$c3e8da3$92d0...@news.astraweb.com>,
> > ge...@eris.prismnet.com (Mark Geary) wrote:
>
> >> Oops, wrong cut and paste. Correct reply below.
> >>
> >> In article <k6slkq$qa$1...@dont-email.me>, Wes Groleau <non...@your.biz>
> >> wrote:
> >>
> >> > find <dir> <conditions> -exec <command> {} \;
> >> > and
> >> > find <dir> <conditions> -exec <command> "{}" \;
> >> >
> >> > _DO_ produce different results when some of the {} contain spaces.
> >> >
> >> > Seen it with my own eyes. Took me quite a while to train myself to not
> >> > forget the quotes. (I developed my habits on systems where most users
> >> > were smart enough to not put spaces in filenames)
> >>
> >> Can you give some examples where it matters? I tried it on Mac OS 10.6
> >> and didn't see any difference
>
> > Frankly, it's been so long since I;ve seen it, I don;t recall the
> > details, other than that adding quotes around {} fixed the issue. Sorry
> > I can't be more specific. It's quite possible it was required in an
> > older version of Mac OS X at some point, under certain circumstances. It
> > bit me once, and from then on I trained myself to use quotes around the
> > {}. Now that this discussion is happening, I haven't yet been able to
> > reproduce it. Perhaps it's time to change my habits. : )
>
> > In article <5093cfe7$0$27173$c3e8da3$92d0...@news.astraweb.com>,
> > ge...@eris.prismnet.com (Mark Geary) wrote:
>
> >> Oops, wrong cut and paste. Correct reply below.
> >>
> >> In article <k6slkq$qa$1...@dont-email.me>, Wes Groleau <non...@your.biz>
> >> wrote:
> >>
> >> > find <dir> <conditions> -exec <command> {} \;
> >> > and
> >> > find <dir> <conditions> -exec <command> "{}" \;
> >> >
> >> > _DO_ produce different results when some of the {} contain spaces.
> >> >
> >> > Seen it with my own eyes. Took me quite a while to train myself to not
> >> > forget the quotes. (I developed my habits on systems where most users
> >> > were smart enough to not put spaces in filenames)
> >>
> >> Can you give some examples where it matters? I tried it on Mac OS 10.6
> >> and didn't see any difference
>
> > Frankly, it's been so long since I;ve seen it, I don;t recall the
> > details, other than that adding quotes around {} fixed the issue. Sorry
> > I can't be more specific. It's quite possible it was required in an
> > older version of Mac OS X at some point, under certain circumstances. It
> > bit me once, and from then on I trained myself to use quotes around the
> > {}. Now that this discussion is happening, I haven't yet been able to
> > reproduce it. Perhaps it's time to change my habits. : )
>
> I'm thinking the last time I hit it was when I was using Handbrake to
> process an entire folder of videos.
>
> Yeah, here is the command I had to use:
>
> find . -name "*.mkv" -exec handbrake -i "{}" -o "{}.m4v" -Z "Apple TV 2" \;
>
> Doesn't work without the "" marks
OK, that command does require quotes. But not the ones around {}, the
> process an entire folder of videos.
>
> Yeah, here is the command I had to use:
>
> find . -name "*.mkv" -exec handbrake -i "{}" -o "{}.m4v" -Z "Apple TV 2" \;
>
> Doesn't work without the "" marks
ones around *.mkv. That's because the shell expands wildcards unless you
quote them, and find needs to receive the wildcard as a literal,
unexpanded argument (so that it can check whether files in
subdirectories match the pattern).
So my suspicion is that you first tried:
find . -name *.mkv -exec handbrake -i {} -o {}.m4v -Z "Apple TV 2" \;
it worked, and didn't bother to figure out just which quotes were really
needed.
Sometimes you can get away without that quoting -- if there are no
matches for the wildcard, it's left intact (unless you set a shell
option to make it report an error, but it's not the default). So if all
the matching files are in subdirectories, you can type *.mkv without the
quotes.
Barry Margolin
Nov 2, 2012, 6:48:18 PM11/2/12
to
In article <jollyroger-97247...@news.individual.net>,
I agree, it's very likely they modified the shell. But NOT the part
that parses the command line -- there's nothing in that part of the
program that needs to be customized for any operating system.
that parses the command line -- there's nothing in that part of the
program that needs to be customized for any operating system.
Jolly Roger
Nov 2, 2012, 7:59:33 PM11/2/12
to
Wes Groleau
Nov 2, 2012, 9:04:49 PM11/2/12
to
On 11-02-2012 15:00, Paul Sture wrote:
> As a follow up to that, is everyone talking about the version of find
> that comes with OS X, or other *nix distributions?
I'm not everyone, but I was talking about Mac OS X.
> As a follow up to that, is everyone talking about the version of find
> that comes with OS X, or other *nix distributions?
I never had the problem in HPUX or Solaris, because we never put spaces
in filenames there.
--
Wes Groleau
What kind of smiley is C:\ ?
Wes Groleau
Nov 2, 2012, 9:08:32 PM11/2/12
to
to read anything about it.
But here's a hint:
The string from {} is not passed to find, it is generated by find.
Wes Groleau
Nov 2, 2012, 9:14:07 PM11/2/12
to
On 11-02-2012 09:45, Mark Geary wrote:
> Can you give some examples where it matters? I tried it on Mac OS 10.6
> and didn't see any difference:
> Can you give some examples where it matters? I tried it on Mac OS 10.6
>
> ~/zz user$ ls -l
> total 0
> -rw-r--r-- 1 user staff 0 Nov 2 09:19 a
> -rw-r--r-- 1 user staff 0 Nov 2 09:34 b'c
> -rw-r--r-- 1 user staff 0 Nov 2 09:19 c d
> -rw-r--r-- 1 user staff 0 Nov 2 09:19 d e f
> -rw-r--r-- 1 user staff 0 Nov 2 09:35 e{} f [\] g
> -rw-r--r-- 1 user staff 0 Nov 2 09:34 f"g
> ~/zz user$ find . -type f -exec echo "{}" \;
> ./a
> ./b'c
> ./c d
> ./d e f
> ./e{} f [\] g
> ./f"g
> ~/zz user$ find . -type f -exec echo '"{}"' \;
> "./a"
> "./b'c"
> "./c d"
> "./d e f"
> "./e{} f [\] g"
> "./f"g"
Well, for one thing, you didn't compare "{}" and {}
You compared "{}" and '"{}"'
What I used it for most was 'rm' or 'mv'
Wes Groleau
Nov 2, 2012, 9:17:52 PM11/2/12
to
On 11-02-2012 16:10, Jolly Roger wrote:
> Sorry, but being a veteran software developer, I know very well that
> just because something should work a certain way, there is no guarantee
> that a bug or unexpected condition won't change that behavior. It'll
Ditto.
> Sorry, but being a veteran software developer, I know very well that
> just because something should work a certain way, there is no guarantee
> that a bug or unexpected condition won't change that behavior. It'll
> take more than just your assurance for me to just swallow your blanket
> statement that adding quotes couldn't possibly have fixed the problem.
Bit me a lot more than once before I finally got my "muscle memory"
retrained.
Wes Groleau
Nov 2, 2012, 9:24:34 PM11/2/12
to
On 11-02-2012 18:05, Barry Margolin wrote:
> Someone mentioned that it might have been when the default shell on Macs
> was csh. csh's parser is more ad hoc, and has had lots of bugs. Although
> I think Macs always used tcsh, which resolved many of those problems.
> But I wouldn't find it hard to believe that an old version of tcsh had a
> problem where it did the wrong thing with {} -- maybe it reported it as
It's possible that my last occurrence was in 10.3, though it seems more
> Someone mentioned that it might have been when the default shell on Macs
> was csh. csh's parser is more ad hoc, and has had lots of bugs. Although
> I think Macs always used tcsh, which resolved many of those problems.
> But I wouldn't find it hard to believe that an old version of tcsh had a
> problem where it did the wrong thing with {} -- maybe it reported it as
recent. My first OS X was 10.0.3. I know what I (repeatedly) saw, and
so though its fun to argue about, I have no motivation to experiment.
No doubt I will need to use find -exec again some day, and if I remember
this discussion at that time.......
--
Wes Groleau
Words of the Wild Wes
http://Ideas.Lang-Learn.org/WWW
Message has been deleted
Barry Margolin
Nov 3, 2012, 12:54:22 AM11/3/12
to
In article <k71qqg$4ej$2...@dont-email.me>,
But we're not talking about the string from {}, we're talking about the
argument {} itself.
The argument {} is passed to find from the shell. Find replaces replaces
this with the filename and passes that as an argument to the program
being executed.
If find receives the same {} argument whether or not you quoted it, it
will obviously pass the same argument to the program it executes.
Furthermore, if the quotes did somehow manage to get passed to find
because of some bug in the shell, the program being exec'ed would
complain that it couldn't find the file. This is because find doesn't
use the shell to run the -exec command, it just passes the arguments to
the program directly (after replacing {} with the filename). The result
would be that the filename passed to the program would be enclosed in
literal quotes, and when the program tries to open that file it won't be
found because the filename doesn't have quotes in it.
argument {} itself.
The argument {} is passed to find from the shell. Find replaces replaces
this with the filename and passes that as an argument to the program
being executed.
If find receives the same {} argument whether or not you quoted it, it
will obviously pass the same argument to the program it executes.
Furthermore, if the quotes did somehow manage to get passed to find
because of some bug in the shell, the program being exec'ed would
complain that it couldn't find the file. This is because find doesn't
use the shell to run the -exec command, it just passes the arguments to
the program directly (after replacing {} with the filename). The result
would be that the filename passed to the program would be enclosed in
literal quotes, and when the program tries to open that file it won't be
found because the filename doesn't have quotes in it.
Barry Margolin
Nov 3, 2012, 12:56:07 AM11/3/12
to
In article <k71qjh$4ej$1...@dont-email.me>,
version on Linux. But it's probably not the one that's on Solaris or
HPUX.
Wes Groleau <Grolea...@FreeShell.org> wrote:
> On 11-02-2012 15:00, Paul Sture wrote:
> > As a follow up to that, is everyone talking about the version of find
> > that comes with OS X, or other *nix distributions?
>
> I'm not everyone, but I was talking about Mac OS X.
>
> I never had the problem in HPUX or Solaris, because we never put spaces
> in filenames there.
I believe the find that comes with OS X is GNU find, which is also the
> On 11-02-2012 15:00, Paul Sture wrote:
> > As a follow up to that, is everyone talking about the version of find
> > that comes with OS X, or other *nix distributions?
>
> I'm not everyone, but I was talking about Mac OS X.
>
> I never had the problem in HPUX or Solaris, because we never put spaces
> in filenames there.
version on Linux. But it's probably not the one that's on Solaris or
HPUX.
Richard Kettlewell
Nov 3, 2012, 5:27:23 AM11/3/12
to
Lewis <g.k...@gmail.com.dontsendmecopies> writes:
> Try it.
Using a one-liner to show what strings are actually passed to the
subcommand:
araminta$ ls -l
total 0
-rw-rw-r-- 1 richard richard 0 Nov 3 09:23 foo bar.mkv
araminta$ find . -name "*.mkv" -exec perl -e 'print map("Arg: $_\n", @ARGV)' -i {} -o {}.m4v -Z "Apple TV 2" \;
Arg: ./foo bar.mkv
Arg: -o
Arg: ./foo bar.mkv.m4v
Arg: -Z
Arg: Apple TV 2
araminta$ find . -name "*.mkv" -exec perl -e 'print map("Arg: $_\n", @ARGV)' -i "{}" -o "{}.m4v" -Z "Apple TV 2" \;
Arg: ./foo bar.mkv
Arg: -o
Arg: ./foo bar.mkv.m4v
Arg: -Z
Arg: Apple TV 2
You will notice that they are the same either way.
--
http://www.greenend.org.uk/rjk/
Using a one-liner to show what strings are actually passed to the
subcommand:
araminta$ ls -l
total 0
-rw-rw-r-- 1 richard richard 0 Nov 3 09:23 foo bar.mkv
araminta$ find . -name "*.mkv" -exec perl -e 'print map("Arg: $_\n", @ARGV)' -i {} -o {}.m4v -Z "Apple TV 2" \;
Arg: ./foo bar.mkv
Arg: -o
Arg: ./foo bar.mkv.m4v
Arg: -Z
Arg: Apple TV 2
araminta$ find . -name "*.mkv" -exec perl -e 'print map("Arg: $_\n", @ARGV)' -i "{}" -o "{}.m4v" -Z "Apple TV 2" \;
Arg: ./foo bar.mkv
Arg: -o
Arg: ./foo bar.mkv.m4v
Arg: -Z
Arg: Apple TV 2
You will notice that they are the same either way.
--
http://www.greenend.org.uk/rjk/
Richard Kettlewell
Nov 3, 2012, 5:43:13 AM11/3/12
to
Barry Margolin <bar...@alum.mit.edu> writes:
> I believe the find that comes with OS X is GNU find, which is also the
> version on Linux. But it's probably not the one that's on Solaris or
> HPUX.
Apple use the BSD implementation. In the OpenSolaris version the
> I believe the find that comes with OS X is GNU find, which is also the
> version on Linux. But it's probably not the one that's on Solaris or
> HPUX.
copyright message and occasional fragments of source code suggest some
common ancestry with BSD’s find.
--
http://www.greenend.org.uk/rjk/
Richard Kettlewell
Nov 3, 2012, 5:52:24 AM11/3/12
to
Wes Groleau <Grolea...@FreeShell.org> writes:
> But here's a hint:
>
> The string from {} is not passed to find, it is generated by find.
The string passed to find is {} either way; it has no way to know
whether it was quoted or not. You will find the documentation for the
system call used with ‘man execve’; you will notice that there is no
provision for passing metadata about what shell quoting was used. When
find runs the subcommand it bypasses the shell and therefore does not
run into any quoting issues. You will find this around line 700 of
find/function.c.
--
http://www.greenend.org.uk/rjk/
> Richard Kettlewell wrote:
>> I'm afraid you are misremembering. The same string is passed to find in
>> both cases, and its behavior is consequently the same. This is not a
>> matter of opinion, speculation or guesswork; it is a fact about how the
>> shell works, which can be confirmed by inspection, by reading the manual
>> or by experiment.
>
> Since I confirmed over and over by unplanned experiment, I had no need
> to read anything about it.
I suggest you repeat the experiment and actually post your results.
>> I'm afraid you are misremembering. The same string is passed to find in
>> both cases, and its behavior is consequently the same. This is not a
>> matter of opinion, speculation or guesswork; it is a fact about how the
>> shell works, which can be confirmed by inspection, by reading the manual
>> or by experiment.
>
> Since I confirmed over and over by unplanned experiment, I had no need
> to read anything about it.
> But here's a hint:
>
> The string from {} is not passed to find, it is generated by find.
whether it was quoted or not. You will find the documentation for the
system call used with ‘man execve’; you will notice that there is no
provision for passing metadata about what shell quoting was used. When
find runs the subcommand it bypasses the shell and therefore does not
run into any quoting issues. You will find this around line 700 of
find/function.c.
--
http://www.greenend.org.uk/rjk/
Wes Groleau
Nov 3, 2012, 12:08:02 PM11/3/12
to
On 11-03-2012 00:54, Barry Margolin wrote:
> But we're not talking about the string from {}, we're talking about the
> argument {} itself.
>
> The argument {} is passed to find from the shell. Find replaces replaces
> this with the filename and passes that as an argument to the program
> being executed.
>
> If find receives the same {} argument whether or not you quoted it, it
> will obviously pass the same argument to the program it executes.
Since it behaved differently, it clearly did not receive it without the
> But we're not talking about the string from {}, we're talking about the
> argument {} itself.
>
> The argument {} is passed to find from the shell. Find replaces replaces
> this with the filename and passes that as an argument to the program
> being executed.
>
> If find receives the same {} argument whether or not you quoted it, it
> will obviously pass the same argument to the program it executes.
quotes. Furthermore, wildcards after -name also behave differently if
quoted.
--
Wes Groleau
I won't burn your Koran because I don't want you to burn my Bible;
but if you burn my Bible, no one's going to die.
— Robert Rhee
Wes Groleau
Nov 3, 2012, 12:10:12 PM11/3/12
to
On 11-03-2012 05:52, Richard Kettlewell wrote:
> I suggest you repeat the experiment and actually post your results.
I know what I saw. If you think I'm a liar, the chances of my changing
> I suggest you repeat the experiment and actually post your results.
your mind are too low to justify the effort.
--
Wes Groleau
“To compel a man to furnish contributions of money for the propagation
of opinions which he disbelieves and abhors, is sinful and tyrannical.”
— Thomas Jefferson
Richard Kettlewell
Nov 3, 2012, 12:47:08 PM11/3/12
to
Wes Groleau <Grolea...@FreeShell.org> writes:
> Richard Kettlewell wrote:
>> I suggest you repeat the experiment and actually post your results.
>
> I know what I saw. If you think I'm a liar, the chances of my
> changing your mind are too low to justify the effort.
I don’t believe you’re lying; I believe you’re misremembering. If you
> Richard Kettlewell wrote:
>> I suggest you repeat the experiment and actually post your results.
>
> I know what I saw. If you think I'm a liar, the chances of my
> changing your mind are too low to justify the effort.
want to change my mind, all you’d have to do is post an example that
demonstrates things work the way you say they do. It shouldn’t take
more than a minute or two - small beer compared to the time already
expended on this thread.
--
http://www.greenend.org.uk/rjk/
Richard Kettlewell
Nov 3, 2012, 12:50:12 PM11/3/12
to
Wes Groleau <Grolea...@FreeShell.org> writes:
> On 11-03-2012 00:54, Barry Margolin wrote:
>> But we're not talking about the string from {}, we're talking about
>> the argument {} itself.
>>
>> The argument {} is passed to find from the shell. Find replaces
>> replaces this with the filename and passes that as an argument to the
>> program being executed.
>>
>> If find receives the same {} argument whether or not you quoted it,
>> it will obviously pass the same argument to the program it executes.
>
> Since it behaved differently, it clearly did not receive it without
> the quotes.
So post an example demonstrating the difference.
> On 11-03-2012 00:54, Barry Margolin wrote:
>> But we're not talking about the string from {}, we're talking about
>> the argument {} itself.
>>
>> The argument {} is passed to find from the shell. Find replaces
>> replaces this with the filename and passes that as an argument to the
>> program being executed.
>>
>> If find receives the same {} argument whether or not you quoted it,
>> it will obviously pass the same argument to the program it executes.
>
> Since it behaved differently, it clearly did not receive it without
> the quotes.
> Furthermore, wildcards after -name also behave differently if quoted.
matching filenames (if there are any). But it all happens in the shell:
by the time find is executed, wildcards have been expanded and quotes
have been stripped.
--
http://www.greenend.org.uk/rjk/
Message has been deleted
Barry Margolin
Nov 3, 2012, 3:30:40 PM11/3/12
to
In article <k73fh3$351$1...@dont-email.me>,
manage to open the file? There were no quotes in the actual filenames,
and the kernel's open() system call doesn't strip quotes. Neither does
find itself (because then it wouldn't work if the filenames actually
*did* have quotes -- there's nothing prohibiting it).
> Furthermore, wildcards after -name also behave differently if
> quoted.
I know -- didn't you see where I explained that in one of my replies?
Quoting prevents wildcards from being expanded by the shell.
You *do* need quotes around the wildcards. You *don't* need quotes
around {}. As I said in my earlier reply, what you probably did when you
first encountered the problem was to add quotes in both places, rather
than experiment to see which quotes are actually needed (or just figure
it out from basic shell principles -- it's really quite simple).
Wes Groleau <Grolea...@FreeShell.org> wrote:
> On 11-03-2012 00:54, Barry Margolin wrote:
> > But we're not talking about the string from {}, we're talking about the
> > argument {} itself.
> >
> > The argument {} is passed to find from the shell. Find replaces replaces
> > this with the filename and passes that as an argument to the program
> > being executed.
> >
> > If find receives the same {} argument whether or not you quoted it, it
> > will obviously pass the same argument to the program it executes.
>
> Since it behaved differently, it clearly did not receive it without the
> quotes.
But if it received it with the quotes, how did the -exec'ed command
> On 11-03-2012 00:54, Barry Margolin wrote:
> > But we're not talking about the string from {}, we're talking about the
> > argument {} itself.
> >
> > The argument {} is passed to find from the shell. Find replaces replaces
> > this with the filename and passes that as an argument to the program
> > being executed.
> >
> > If find receives the same {} argument whether or not you quoted it, it
> > will obviously pass the same argument to the program it executes.
>
> Since it behaved differently, it clearly did not receive it without the
> quotes.
manage to open the file? There were no quotes in the actual filenames,
and the kernel's open() system call doesn't strip quotes. Neither does
find itself (because then it wouldn't work if the filenames actually
*did* have quotes -- there's nothing prohibiting it).
> Furthermore, wildcards after -name also behave differently if
> quoted.
Quoting prevents wildcards from being expanded by the shell.
You *do* need quotes around the wildcards. You *don't* need quotes
around {}. As I said in my earlier reply, what you probably did when you
first encountered the problem was to add quotes in both places, rather
than experiment to see which quotes are actually needed (or just figure
it out from basic shell principles -- it's really quite simple).
Jolly Roger
Nov 3, 2012, 4:28:27 PM11/3/12
to
In article <slrnk9allf....@mbp55.local>,
Lewis <g.k...@gmail.com.dontsendmecopies> wrote:
> In message <k73fl4$351$2...@dont-email.me>
> put the quotes in. However, that was at least two major OS levels ago
> (10.6.*mumble*).
I know what I saw as well. With this many people having witnessed it,
you'd think the naysayers would get a clue.
Lewis <g.k...@gmail.com.dontsendmecopies> wrote:
> In message <k73fl4$351$2...@dont-email.me>
> Wes Groleau <Grolea...@FreeShell.org> wrote:
> > On 11-03-2012 05:52, Richard Kettlewell wrote:
> >> I suggest you repeat the experiment and actually post your results.
>
> > I know what I saw. If you think I'm a liar, the chances of my changing
> > your mind are too low to justify the effort.
>
> I know that when i was converting a whole slue of mkvs to m4v I had to
> > On 11-03-2012 05:52, Richard Kettlewell wrote:
> >> I suggest you repeat the experiment and actually post your results.
>
> > I know what I saw. If you think I'm a liar, the chances of my changing
> > your mind are too low to justify the effort.
>
> put the quotes in. However, that was at least two major OS levels ago
> (10.6.*mumble*).
I know what I saw as well. With this many people having witnessed it,
you'd think the naysayers would get a clue.
Paul Sture
Nov 3, 2012, 4:36:01 PM11/3/12
to
In article <jollyroger-97247...@news.individual.net>,
The utilities supplied with OS X are often quite down-revision from the
latest too.
I know that some feature or other of bash back in Tiger or Panther days
was missing and I compiled a later version of bash to get that
functionality (I bottled out in using it though just in case it caused
problems).
For example, Scientific Linux (binary compatible with RHEL, which is
hardly the latest and greatest because it stresses stability rather than
new features appears to be a couple of years newer than OS X:
bash --version
GNU bash, version 4.1.2(1)-release (x86_64-redhat-linux-gnu)
Copyright (C) 2009 Free Software Foundation, Inc.
Mountain Lion
bash --version
GNU bash, version 3.2.48(1)-release (x86_64-apple-darwin12)
Copyright (C) 2007 Free Software Foundation, Inc.
--
Paul Sture
latest too.
I know that some feature or other of bash back in Tiger or Panther days
was missing and I compiled a later version of bash to get that
functionality (I bottled out in using it though just in case it caused
problems).
For example, Scientific Linux (binary compatible with RHEL, which is
hardly the latest and greatest because it stresses stability rather than
new features appears to be a couple of years newer than OS X:
bash --version
GNU bash, version 4.1.2(1)-release (x86_64-redhat-linux-gnu)
Copyright (C) 2009 Free Software Foundation, Inc.
Mountain Lion
bash --version
GNU bash, version 3.2.48(1)-release (x86_64-apple-darwin12)
Copyright (C) 2007 Free Software Foundation, Inc.
--
Paul Sture
Paul Sture
Nov 3, 2012, 4:49:13 PM11/3/12
to
In article <barmar-30D67B....@news.eternal-september.org>,
Barry Margolin <bar...@alum.mit.edu> wrote:
> In article <nospam-3D7EBD....@news.chingola.ch>,
> Paul Sture <nos...@sture.ch> wrote:
>
> > That reminds me of something I came across in VMS many years ago. One
> > way to insert double quotes into a string using that CLI was to double
> > them up e.g.
> >
> > string = "some text ""quoted substring"" more text"
> >
> > Yet with one particular utility which talked to a foreign system (via
> > FTP or NFS IIRC), you needed to triple those quotes. We never worked
> > out why, but were happy that it worked.
>
> Things do get tricky when you need to get a quoted substring into the
> arguments of a program. On Unix, the challenge often arises when you're
> doing:
>
> ssh hostname <command>
>
> If the command you're trying to run contains quoted strings and
> variables, figuring out all the quoting and escaping can be difficult.
> I've nearly driven myself crazy trying to run awk commands like this,
> since you need to ensure that $ is NOT expanded either locally or in the
> remote shell, because it has to get into awk's literal argument.
I have run into that one too. You can easily start tearing your hair
out.
> I used to use Multics, which also use quote doubling. Its equivalent to
> Unix's "if" and "for" commands required putting the body as a single
> quoted argument, so if you had nested conditionals and loops you could
> easily end up with a sequence of 8 or 16 quotes (actually, this was only
> necessary for interactive commands -- it had a separate mechanism for
> running scripts that added its own directives for flow control).
That reminds me. I had a devil of a job trying to escape the apostrophe
in "iWork '09" using Applescript. I finally found a solution, but when
I came across a comment that the behaviour might change in a future
version of OS X, I thought "Nuts, I'm not going through that again", and
wrote a temporary file to execute instead. I didn't like that solution
but it was going to be maintainable...
--
Paul Sture
Barry Margolin <bar...@alum.mit.edu> wrote:
> In article <nospam-3D7EBD....@news.chingola.ch>,
> Paul Sture <nos...@sture.ch> wrote:
>
> > That reminds me of something I came across in VMS many years ago. One
> > way to insert double quotes into a string using that CLI was to double
> > them up e.g.
> >
> > string = "some text ""quoted substring"" more text"
> >
> > Yet with one particular utility which talked to a foreign system (via
> > FTP or NFS IIRC), you needed to triple those quotes. We never worked
> > out why, but were happy that it worked.
>
> Things do get tricky when you need to get a quoted substring into the
> arguments of a program. On Unix, the challenge often arises when you're
> doing:
>
> ssh hostname <command>
>
> If the command you're trying to run contains quoted strings and
> variables, figuring out all the quoting and escaping can be difficult.
> I've nearly driven myself crazy trying to run awk commands like this,
> since you need to ensure that $ is NOT expanded either locally or in the
> remote shell, because it has to get into awk's literal argument.
I have run into that one too. You can easily start tearing your hair
out.
> I used to use Multics, which also use quote doubling. Its equivalent to
> Unix's "if" and "for" commands required putting the body as a single
> quoted argument, so if you had nested conditionals and loops you could
> easily end up with a sequence of 8 or 16 quotes (actually, this was only
> necessary for interactive commands -- it had a separate mechanism for
> running scripts that added its own directives for flow control).
That reminds me. I had a devil of a job trying to escape the apostrophe
in "iWork '09" using Applescript. I finally found a solution, but when
I came across a comment that the behaviour might change in a future
version of OS X, I thought "Nuts, I'm not going through that again", and
wrote a temporary file to execute instead. I didn't like that solution
but it was going to be maintainable...
--
Paul Sture
Paul Sture
Nov 3, 2012, 4:53:00 PM11/3/12
to
In article <k71qjh$4ej$1...@dont-email.me>,
them with hyphens or underscores _where I can_.
This makes shifting them around from one OS to another much simpler.
--
Paul Sture
Wes Groleau <Grolea...@FreeShell.org> wrote:
> On 11-02-2012 15:00, Paul Sture wrote:
> > As a follow up to that, is everyone talking about the version of find
> > that comes with OS X, or other *nix distributions?
>
> I'm not everyone, but I was talking about Mac OS X.
>
> I never had the problem in HPUX or Solaris, because we never put spaces
> in filenames there.
I too have an aversion to spaces in filenames, and will usually replace
> On 11-02-2012 15:00, Paul Sture wrote:
> > As a follow up to that, is everyone talking about the version of find
> > that comes with OS X, or other *nix distributions?
>
> I'm not everyone, but I was talking about Mac OS X.
>
> I never had the problem in HPUX or Solaris, because we never put spaces
> in filenames there.
them with hyphens or underscores _where I can_.
This makes shifting them around from one OS to another much simpler.
--
Paul Sture
Paul Sture
Nov 3, 2012, 5:01:56 PM11/3/12
to
In article <87objfh...@araminta.anjou.terraraq.org.uk>,
My Linux systems certainly use GNU find, and --version gives you version
details.
find --version isn't recognised on either OS X or FreeBSD.
--
Paul Sture
details.
find --version isn't recognised on either OS X or FreeBSD.
--
Paul Sture
Paul Sture
Nov 3, 2012, 5:04:11 PM11/3/12
to
In article <021120121539469219%nos...@nospam.invalid>,
nospam <nos...@nospam.invalid> wrote:
> In article <slrnk98ipo....@mbp55.local>, Lewis
> <g.k...@gmail.com.dontsendmecopies> wrote:
>
> > > Which version of OS X was it that introduced bash as the default shell
> > > when creating accounts? 10.1 used tcsh, and my work servers at that
> > > time csh was in use.
> >
> > I think the change was in 10.5, but I'd changed well before that, so I
> > am not positive.
>
> *well* before that. it changed in 10.3.
And as someone else pointed out, for accounts created on previous
versions, the default was tcsh. I switched to bash mainly because a lot
of the code examples out there on the web assume bash, but there were
other things like command completion IIRC.
--
Paul Sture
nospam <nos...@nospam.invalid> wrote:
> In article <slrnk98ipo....@mbp55.local>, Lewis
> <g.k...@gmail.com.dontsendmecopies> wrote:
>
> > > Which version of OS X was it that introduced bash as the default shell
> > > when creating accounts? 10.1 used tcsh, and my work servers at that
> > > time csh was in use.
> >
> > I think the change was in 10.5, but I'd changed well before that, so I
> > am not positive.
>
> *well* before that. it changed in 10.3.
And as someone else pointed out, for accounts created on previous
versions, the default was tcsh. I switched to bash mainly because a lot
of the code examples out there on the web assume bash, but there were
other things like command completion IIRC.
--
Paul Sture
Jolly Roger
Nov 3, 2012, 5:14:43 PM11/3/12
to
In article <nospam-7DDE4D....@news.chingola.ch>,
Meh. As long as software /scripts are written correctly, spaces
shouldn't be a problem.
shouldn't be a problem.
Wes Groleau
Nov 3, 2012, 5:57:59 PM11/3/12
to
On 11-03-2012 17:14, Jolly Roger wrote:
--
Wes Groleau
Beware of the man who works hard to learn something, learns
it, and finds himself no wiser than before ... He is full of
murderous resentment of people who are ignorant without having
come by their ignorance the hard way.
— Kurt Vonnegut
>>> I never had the problem in HPUX or Solaris, because we never put spaces
>>> in filenames there.
>>
>> I too have an aversion to spaces in filenames, and will usually replace
>> them with hyphens or underscores _where I can_.
>>
>> This makes shifting them around from one OS to another much simpler.
>
> Meh. As long as software /scripts are written correctly, spaces
> shouldn't be a problem.
A veteran software engineer ought to know one can't count on that. :-)
>>> in filenames there.
>>
>> I too have an aversion to spaces in filenames, and will usually replace
>> them with hyphens or underscores _where I can_.
>>
>> This makes shifting them around from one OS to another much simpler.
>
> Meh. As long as software /scripts are written correctly, spaces
> shouldn't be a problem.
--
Wes Groleau
Beware of the man who works hard to learn something, learns
it, and finds himself no wiser than before ... He is full of
murderous resentment of people who are ignorant without having
come by their ignorance the hard way.
— Kurt Vonnegut
Jolly Roger
Nov 3, 2012, 6:01:12 PM11/3/12
to
In article <k74417$476$1...@dont-email.me>,
Wes Groleau <Grolea...@FreeShell.org> wrote:
> On 11-03-2012 17:14, Jolly Roger wrote:
> > Paul Sture <nos...@sture.ch> wrote:
> >> Wes Groleau <Grolea...@FreeShell.org> wrote:
> >>> I never had the problem in HPUX or Solaris, because we never put spaces
> >>> in filenames there.
> >>
> >> I too have an aversion to spaces in filenames, and will usually replace
> >> them with hyphens or underscores _where I can_.
> >>
> >> This makes shifting them around from one OS to another much simpler.
> >
> > Meh. As long as software /scripts are written correctly, spaces
> > shouldn't be a problem.
>
> A veteran software engineer ought to know one can't count on that. :-)
You surely can with your own software.
> On 11-03-2012 17:14, Jolly Roger wrote:
> > Paul Sture <nos...@sture.ch> wrote:
> >> Wes Groleau <Grolea...@FreeShell.org> wrote:
> >>> I never had the problem in HPUX or Solaris, because we never put spaces
> >>> in filenames there.
> >>
> >> I too have an aversion to spaces in filenames, and will usually replace
> >> them with hyphens or underscores _where I can_.
> >>
> >> This makes shifting them around from one OS to another much simpler.
> >
> > Meh. As long as software /scripts are written correctly, spaces
> > shouldn't be a problem.
>
> A veteran software engineer ought to know one can't count on that. :-)
Wes Groleau
Nov 3, 2012, 6:01:37 PM11/3/12
to
On 11-03-2012 16:28, Jolly Roger wrote:
> I know what I saw as well. With this many people having witnessed it,
> you'd think the naysayers would get a clue.
Ah, well, it's three against three--and one of the three has a manual.
> I know what I saw as well. With this many people having witnessed it,
> you'd think the naysayers would get a clue.
As we all know, if it Resides in The FM, ....
--
Wes Groleau
ASCII stupid question, get a stupid ANSI
Paul Sture
Nov 3, 2012, 6:32:06 PM11/3/12
to
In article <jollyroger-3EC91...@news.individual.net>,
If I strip the spaces at creation time I can also put them on a web
server without too much effort.
--
Paul Sture
Jolly Roger <jolly...@pobox.com> wrote:
> In article <nospam-7DDE4D....@news.chingola.ch>,
> Paul Sture <nos...@sture.ch> wrote:
>
> > In article <k71qjh$4ej$1...@dont-email.me>,
> > Wes Groleau <Grolea...@FreeShell.org> wrote:
> >
> > > On 11-02-2012 15:00, Paul Sture wrote:
> > > > As a follow up to that, is everyone talking about the version of find
> > > > that comes with OS X, or other *nix distributions?
> > >
> > > I'm not everyone, but I was talking about Mac OS X.
> > >
> > > I never had the problem in HPUX or Solaris, because we never put spaces
> > > in filenames there.
> >
> > I too have an aversion to spaces in filenames, and will usually replace
> > them with hyphens or underscores _where I can_.
> >
> > This makes shifting them around from one OS to another much simpler.
>
> Meh. As long as software /scripts are written correctly, spaces
> shouldn't be a problem.
But not when you have come across the extended filenames in VMS :-)
> In article <nospam-7DDE4D....@news.chingola.ch>,
> Paul Sture <nos...@sture.ch> wrote:
>
> > In article <k71qjh$4ej$1...@dont-email.me>,
> > Wes Groleau <Grolea...@FreeShell.org> wrote:
> >
> > > On 11-02-2012 15:00, Paul Sture wrote:
> > > > As a follow up to that, is everyone talking about the version of find
> > > > that comes with OS X, or other *nix distributions?
> > >
> > > I'm not everyone, but I was talking about Mac OS X.
> > >
> > > I never had the problem in HPUX or Solaris, because we never put spaces
> > > in filenames there.
> >
> > I too have an aversion to spaces in filenames, and will usually replace
> > them with hyphens or underscores _where I can_.
> >
> > This makes shifting them around from one OS to another much simpler.
>
> Meh. As long as software /scripts are written correctly, spaces
> shouldn't be a problem.
If I strip the spaces at creation time I can also put them on a web
server without too much effort.
--
Paul Sture
Message has been deleted
Jolly Roger
Nov 3, 2012, 8:22:45 PM11/3/12
to
In article <slrnk9bd2n....@mbp55.local>,
Lewis <g.k...@gmail.com.dontsendmecopies> wrote:
> In message <jollyroger-3EC91...@news.individual.net>
> To_Kill_A_Mockingbird_(1962).m4v is just fugly. And the ()'s have to be
> escaped too, so there's all sorts of issues *anyway*.
When computers make life harder for us, something's not right. If a
piece of software fucks up because of a perfectly valid printable
character, something has gone horribly wrong with usability. It's up to
software developers to produce usable software.
Lewis <g.k...@gmail.com.dontsendmecopies> wrote:
> In message <jollyroger-3EC91...@news.individual.net>
> Jolly Roger <jolly...@pobox.com> wrote:
> > In article <nospam-7DDE4D....@news.chingola.ch>,
> > Paul Sture <nos...@sture.ch> wrote:
>
> >> In article <k71qjh$4ej$1...@dont-email.me>,
> >> Wes Groleau <Grolea...@FreeShell.org> wrote:
> >>
> >> > On 11-02-2012 15:00, Paul Sture wrote:
> >> > > As a follow up to that, is everyone talking about the version of find
> >> > > that comes with OS X, or other *nix distributions?
> >> >
> >> > I'm not everyone, but I was talking about Mac OS X.
> >> >
> >> > I never had the problem in HPUX or Solaris, because we never put spaces
> >> > in filenames there.
> >>
> >> I too have an aversion to spaces in filenames, and will usually replace
> >> them with hyphens or underscores _where I can_.
> >>
> >> This makes shifting them around from one OS to another much simpler.
>
> > Meh. As long as software /scripts are written correctly, spaces
> > shouldn't be a problem.
>
> Besides, naming a movei file, for example,
> > In article <nospam-7DDE4D....@news.chingola.ch>,
> > Paul Sture <nos...@sture.ch> wrote:
>
> >> In article <k71qjh$4ej$1...@dont-email.me>,
> >> Wes Groleau <Grolea...@FreeShell.org> wrote:
> >>
> >> > On 11-02-2012 15:00, Paul Sture wrote:
> >> > > As a follow up to that, is everyone talking about the version of find
> >> > > that comes with OS X, or other *nix distributions?
> >> >
> >> > I'm not everyone, but I was talking about Mac OS X.
> >> >
> >> > I never had the problem in HPUX or Solaris, because we never put spaces
> >> > in filenames there.
> >>
> >> I too have an aversion to spaces in filenames, and will usually replace
> >> them with hyphens or underscores _where I can_.
> >>
> >> This makes shifting them around from one OS to another much simpler.
>
> > Meh. As long as software /scripts are written correctly, spaces
> > shouldn't be a problem.
>
> To_Kill_A_Mockingbird_(1962).m4v is just fugly. And the ()'s have to be
> escaped too, so there's all sorts of issues *anyway*.
When computers make life harder for us, something's not right. If a
piece of software fucks up because of a perfectly valid printable
character, something has gone horribly wrong with usability. It's up to
software developers to produce usable software.
Barry Margolin
Nov 3, 2012, 11:12:54 PM11/3/12
to
> In article <nospam-7DDE4D....@news.chingola.ch>,
> Paul Sture <nos...@sture.ch> wrote:
>
> > In article <k71qjh$4ej$1...@dont-email.me>,
> > Wes Groleau <Grolea...@FreeShell.org> wrote:
> >
> > > On 11-02-2012 15:00, Paul Sture wrote:
> > > > As a follow up to that, is everyone talking about the version of find
> > > > that comes with OS X, or other *nix distributions?
> > >
> > > I'm not everyone, but I was talking about Mac OS X.
> > >
> > > I never had the problem in HPUX or Solaris, because we never put spaces
> > > in filenames there.
> >
> > I too have an aversion to spaces in filenames, and will usually replace
> > them with hyphens or underscores _where I can_.
> >
> > This makes shifting them around from one OS to another much simpler.
>
> Meh. As long as software /scripts are written correctly, spaces
> shouldn't be a problem.
That's a pretty big "if" there. There are lots of poorly written scripts.
> Paul Sture <nos...@sture.ch> wrote:
>
> > In article <k71qjh$4ej$1...@dont-email.me>,
> > Wes Groleau <Grolea...@FreeShell.org> wrote:
> >
> > > On 11-02-2012 15:00, Paul Sture wrote:
> > > > As a follow up to that, is everyone talking about the version of find
> > > > that comes with OS X, or other *nix distributions?
> > >
> > > I'm not everyone, but I was talking about Mac OS X.
> > >
> > > I never had the problem in HPUX or Solaris, because we never put spaces
> > > in filenames there.
> >
> > I too have an aversion to spaces in filenames, and will usually replace
> > them with hyphens or underscores _where I can_.
> >
> > This makes shifting them around from one OS to another much simpler.
>
> Meh. As long as software /scripts are written correctly, spaces
> shouldn't be a problem.
Barry Margolin
Nov 3, 2012, 11:16:10 PM11/3/12
to
In article <jollyroger-A24A4...@news.individual.net>,
The problem is that we're asking them to perform complex tasks, and
they're very dumb. Shells and commands make heavy use of punctuation
characters to have special meanings, because it would be inconvenient to
have to express everything with words. They're not smart enough to
figure out automatically when a character should have its special
meaning, and when it should be taken literally -- they rely on us to
tell them (by quoting and escaping).
they're very dumb. Shells and commands make heavy use of punctuation
characters to have special meanings, because it would be inconvenient to
have to express everything with words. They're not smart enough to
figure out automatically when a character should have its special
meaning, and when it should be taken literally -- they rely on us to
tell them (by quoting and escaping).
nospam
Nov 4, 2012, 12:05:08 AM11/4/12
to
In article <jollyroger-3EC91...@news.individual.net>,
Jolly Roger <jolly...@pobox.com> wrote:
> > > I never had the problem in HPUX or Solaris, because we never put spaces
> > > in filenames there.
> >
> > I too have an aversion to spaces in filenames, and will usually replace
> > them with hyphens or underscores _where I can_.
> >
> > This makes shifting them around from one OS to another much simpler.
>
> Meh. As long as software /scripts are written correctly, spaces
> shouldn't be a problem.
like in itunes 2.0, you mean?
> > > I never had the problem in HPUX or Solaris, because we never put spaces
> > > in filenames there.
> >
> > I too have an aversion to spaces in filenames, and will usually replace
> > them with hyphens or underscores _where I can_.
> >
> > This makes shifting them around from one OS to another much simpler.
>
> Meh. As long as software /scripts are written correctly, spaces
> shouldn't be a problem.
Wes Groleau
Nov 4, 2012, 1:41:35 AM11/4/12
to
On 11-03-2012 18:01, Jolly Roger wrote:
> In article <k74417$476$1...@dont-email.me>,
> Wes Groleau <Grolea...@FreeShell.org> wrote:
>
>> On 11-03-2012 17:14, Jolly Roger wrote:
>>> Paul Sture <nos...@sture.ch> wrote:
>>>> Wes Groleau <Grolea...@FreeShell.org> wrote:
>>>>> I never had the problem in HPUX or Solaris, because we never put spaces
>>>>> in filenames there.
>>>>
>>>> I too have an aversion to spaces in filenames, and will usually replace
>>>> them with hyphens or underscores _where I can_.
>>>>
>>>> This makes shifting them around from one OS to another much simpler.
>>>
>>> Meh. As long as software /scripts are written correctly, spaces
>>> shouldn't be a problem.
>>
>> A veteran software engineer ought to know one can't count on that. :-)
>
> You surely can with your own software.
"veteran software engineer" is an allusion to a thread in which it
> In article <k74417$476$1...@dont-email.me>,
> Wes Groleau <Grolea...@FreeShell.org> wrote:
>
>> On 11-03-2012 17:14, Jolly Roger wrote:
>>> Paul Sture <nos...@sture.ch> wrote:
>>>> Wes Groleau <Grolea...@FreeShell.org> wrote:
>>>>> I never had the problem in HPUX or Solaris, because we never put spaces
>>>>> in filenames there.
>>>>
>>>> I too have an aversion to spaces in filenames, and will usually replace
>>>> them with hyphens or underscores _where I can_.
>>>>
>>>> This makes shifting them around from one OS to another much simpler.
>>>
>>> Meh. As long as software /scripts are written correctly, spaces
>>> shouldn't be a problem.
>>
>> A veteran software engineer ought to know one can't count on that. :-)
>
> You surely can with your own software.
wasn't my software that was in question. :-)
--
Wes Groleau
Is it an on-line compliment to call someone a Net Wit ?
0 new messages