Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.unix.programmer > #14303 > unrolled thread
| Started by | Spiros Bousbouras <spibou@gmail.com> |
|---|---|
| First post | 2023-08-13 13:55 +0000 |
| Last post | 2023-08-14 21:14 +0000 |
| Articles | 20 on this page of 151 — 33 participants |
Back to article view | Back to comp.unix.programmer
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: Piping to stdin Spiros Bousbouras <spibou@gmail.com> - 2023-08-13 13:55 +0000
Re: Piping to stdin Spiros Bousbouras <spibou@gmail.com> - 2023-08-13 14:27 +0000
Re: Piping to stdin gazelle@shell.xmission.com (Kenny McCormack) - 2023-08-14 00:59 +0000
Re: Piping to stdin Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-14 03:07 +0000
Re: Piping to stdin gazelle@shell.xmission.com (Kenny McCormack) - 2023-08-14 03:12 +0000
Re: Piping to stdin kalevi@kolttonen.fi (Kalevi Kolttonen) - 2023-08-14 15:14 +0000
Re: Piping to stdin "Gary R. Schmidt" <grschmidt@acm.org> - 2023-08-15 12:50 +1000
Re: Piping to stdin Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-15 04:59 +0000
Re: Piping to stdin Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-14 23:15 -0700
Re: Piping to stdin Richard Kettlewell <invalid@invalid.invalid> - 2023-08-15 08:50 +0100
Dealing with weird filenames (Was: Piping to stdin) gazelle@shell.xmission.com (Kenny McCormack) - 2023-08-15 08:10 +0000
Re: Piping to stdin David Brown <david.brown@hesbynett.no> - 2023-08-15 15:34 +0200
Re: Piping to stdin Richard Harnden <richard.nospam@gmail.com> - 2023-08-15 19:50 +0100
Re: Piping to stdin scott@slp53.sl.home (Scott Lurndal) - 2023-08-15 20:16 +0000
Re: Piping to stdin vallor <vallor@cultnix.org> - 2023-08-16 06:34 +0000
Re: Piping to stdin Richard Kettlewell <invalid@invalid.invalid> - 2023-08-16 17:39 +0100
Re: Piping to stdin scott@slp53.sl.home (Scott Lurndal) - 2023-08-16 17:37 +0000
Re: Piping to stdin gazelle@shell.xmission.com (Kenny McCormack) - 2023-08-16 17:43 +0000
Re: Piping to stdin Spiros Bousbouras <spibou@gmail.com> - 2023-08-16 19:22 +0000
Re: Piping to stdin Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-16 20:10 +0000
Re: Piping to stdin Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-16 20:11 +0000
Re: Piping to stdin Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-16 13:35 -0700
Re: Piping to stdin Geoff Clare <geoff@clare.See-My-Signature.invalid> - 2023-08-17 13:34 +0100
Re: Piping to stdin Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-17 14:27 -0700
Re: Piping to stdin Phil Carmody <pc+usenet@asdf.org> - 2023-08-17 14:51 +0300
Re: Piping to stdin James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-08-16 01:37 -0400
Re: Piping to stdin David Brown <david.brown@hesbynett.no> - 2023-08-16 13:14 +0200
Re: Piping to stdin Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2023-08-15 12:08 -0600
Re: Piping to stdin Richard Harnden <richard.nospam@gmail.com> - 2023-08-16 09:32 +0100
Re: Piping to stdin Phil Carmody <pc+usenet@asdf.org> - 2023-08-16 17:27 +0300
Re: Piping to stdin kalevi@kolttonen.fi (Kalevi Kolttonen) - 2023-08-15 14:30 +0000
Re: Piping to stdin Giovanni <lsodgf0@home.net.it> - 2023-08-15 17:14 +0200
Re: Piping to stdin gazelle@shell.xmission.com (Kenny McCormack) - 2023-08-15 15:48 +0000
Re: Piping to stdin kalevi@kolttonen.fi (Kalevi Kolttonen) - 2023-08-15 16:12 +0000
Re: Piping to stdin Muttley@dastardlyhq.com - 2023-08-15 16:15 +0000
Re: Piping to stdin kalevi@kolttonen.fi (Kalevi Kolttonen) - 2023-08-15 16:22 +0000
Re: Piping to stdin Muttley@dastardlyhq.com - 2023-08-17 10:26 +0000
Re: Piping to stdin kalevi@kolttonen.fi (Kalevi Kolttonen) - 2023-08-17 14:23 +0000
Re: Piping to stdin scott@slp53.sl.home (Scott Lurndal) - 2023-08-17 15:25 +0000
Re: Piping to stdin Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-15 17:33 +0000
Re: Piping to stdin Phil Carmody <pc+usenet@asdf.org> - 2023-08-15 23:32 +0300
Re: Piping to stdin Muttley@dastardlyhq.com - 2023-08-17 10:32 +0000
Re: Piping to stdin Phil Carmody <pc+usenet@asdf.org> - 2023-08-17 14:57 +0300
Re: Piping to stdin Geoff Clare <geoff@clare.See-My-Signature.invalid> - 2023-08-17 13:49 +0100
Re: Piping to stdin Muttley@dastardlyhq.com - 2023-08-17 15:15 +0000
Wrecking a good thing? (Was: Piping to stdin) gazelle@shell.xmission.com (Kenny McCormack) - 2023-08-17 14:09 +0000
Re: Wrecking a good thing? Phil Carmody <pc+usenet@asdf.org> - 2023-08-18 00:39 +0300
Re: Wrecking a good thing? (Was: Piping to stdin) David Brown <david.brown@hesbynett.no> - 2023-08-18 11:17 +0200
Re: Piping to stdin Muttley@dastardlyhq.com - 2023-08-17 15:14 +0000
Re: Piping to stdin Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-17 13:52 +0000
Re: Piping to stdin Muttley@dastardlyhq.com - 2023-08-17 15:20 +0000
Re: Piping to stdin Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-17 13:43 -0700
Re: Piping to stdin David Brown <david.brown@hesbynett.no> - 2023-08-18 11:28 +0200
Re: Piping to stdin Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-17 21:52 +0100
Re: Piping to stdin Phil Carmody <pc+usenet@asdf.org> - 2023-08-19 13:33 +0300
Re: Piping to stdin Oğuz <oguzismailuysal@gmail.com> - 2023-08-19 16:15 +0300
Re: Piping to stdin Muttley@dastardlyhq.com - 2023-08-19 14:48 +0000
Re: Piping to stdin scott@slp53.sl.home (Scott Lurndal) - 2023-08-20 17:24 +0000
Re: Piping to stdin Muttley@dastardlyhq.com - 2023-08-20 19:21 +0000
Re: Piping to stdin Rainer Weikusat <rweikusat@talktalk.net> - 2023-08-20 21:57 +0100
What language is this? (Was: Piping to stdin) gazelle@shell.xmission.com (Kenny McCormack) - 2023-08-20 22:33 +0000
Re: What language is this? (Was: Piping to stdin) scott@slp53.sl.home (Scott Lurndal) - 2023-08-21 01:26 +0000
Re: What language is this? (Was: Piping to stdin) gazelle@shell.xmission.com (Kenny McCormack) - 2023-08-21 02:57 +0000
Re: What language is this? Rainer Weikusat <rweikusat@talktalk.net> - 2023-08-21 17:16 +0100
Re: What language is this? gazelle@shell.xmission.com (Kenny McCormack) - 2023-08-21 19:10 +0000
Re: What language is this? Rainer Weikusat <rweikusat@talktalk.net> - 2023-08-21 20:31 +0100
Re: What language is this? gazelle@shell.xmission.com (Kenny McCormack) - 2023-08-21 20:29 +0000
Re: What language is this? Rainer Weikusat <rweikusat@talktalk.net> - 2023-08-21 21:48 +0100
Re: What language is this? (Was: Piping to stdin) Muttley@dastardlyhq.com - 2023-08-21 06:50 +0000
Re: Piping to stdin Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-19 21:14 +0100
Re: Piping to stdin kalevi@kolttonen.fi (Kalevi Kolttonen) - 2023-08-20 02:02 +0000
Long filenames in DOS/Windows and Unix/Linux (Was: Piping to stdin) gazelle@shell.xmission.com (Kenny McCormack) - 2024-08-31 05:57 +0000
Re: Long filenames in DOS/Windows and Unix/Linux Richard Kettlewell <invalid@invalid.invalid> - 2024-08-31 09:27 +0100
Re: Long filenames in DOS/Windows and Unix/Linux Muttley@dastardlyhq.com - 2024-08-31 08:39 +0000
Re: Long filenames in DOS/Windows and Unix/Linux Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-08-31 23:34 +0000
Re: Long filenames in DOS/Windows and Unix/Linux Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-09-01 07:03 +0000
Re: Long filenames in DOS/Windows and Unix/Linux Nuno Silva <nunojsilva@invalid.invalid> - 2024-09-01 09:10 +0100
Re: Long filenames in DOS/Windows and Unix/Linux Helmut Waitzmann <nn.throttle@xoxy.net> - 2024-09-01 19:51 +0200
Putting arbitrary characters into the shell command line (was: Long filenames in DOS/Windows and Unix/Linux) Helmut Waitzmann <nn.throttle@xoxy.net> - 2024-09-01 21:07 +0200
Re: Long filenames in DOS/Windows and Unix/Linux Wayne <wayne@nospam.invalid> - 2024-09-03 13:56 -0400
Re: Long filenames in DOS/Windows and Unix/Linux Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-09-03 21:54 +0000
Re: Long filenames in DOS/Windows and Unix/Linux Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-09-08 07:24 +0200
Arbitrary characters in filenames (was: Long filenames in DOS/Windows and Unix/Linux) Helmut Waitzmann <nn.throttle@xoxy.net> - 2024-09-01 20:06 +0200
Re: Long filenames in DOS/Windows and Unix/Linux (Was: Piping to stdin) Muttley@dastardlyhq.com - 2024-08-31 08:37 +0000
Re: Long filenames in DOS/Windows and Unix/Linux (Was: Piping to stdin) John Ames <commodorejohn@gmail.com> - 2024-09-03 08:44 -0700
Re: Long filenames in DOS/Windows and Unix/Linux (Was: Piping to stdin) scott@slp53.sl.home (Scott Lurndal) - 2024-09-03 15:47 +0000
Re: Long filenames in DOS/Windows and Unix/Linux (Was: Piping to stdin) Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2024-09-03 15:54 +0000
Re: Long filenames in DOS/Windows and Unix/Linux (Was: Piping to stdin) gazelle@shell.xmission.com (Kenny McCormack) - 2024-09-03 16:10 +0000
Re: Long filenames in DOS/Windows and Unix/Linux (Was: Piping to Muttley@dastardlyhq.com - 2024-09-04 07:27 +0000
User surveys (Was: Long filenames in DOS/Windows and Unix/Linux (Was: Piping to) gazelle@shell.xmission.com (Kenny McCormack) - 2024-09-04 11:27 +0000
Re: User surveys (Was: Long filenames in DOS/Windows and Unix/Linux (Was: Piping to) Muttley@dastardlyhq.com - 2024-09-04 13:12 +0000
Re: Long filenames in DOS/Windows and Unix/Linux (Was: Piping to stdin) Kaz Kylheku <643-408-1753@kylheku.com> - 2024-09-03 17:37 +0000
Re: Long filenames in DOS/Windows and Unix/Linux (Was: Piping to stdin) John Ames <commodorejohn@gmail.com> - 2024-09-03 11:39 -0700
Re: Long filenames in DOS/Windows and Unix/Linux (Was: Piping to stdin) Kaz Kylheku <643-408-1753@kylheku.com> - 2024-09-03 20:11 +0000
Re: Long filenames in DOS/Windows and Unix/Linux (Was: Piping to stdin) John Ames <commodorejohn@gmail.com> - 2024-09-03 13:25 -0700
Re: Long filenames in DOS/Windows and Unix/Linux (Was: Piping to stdin) scott@slp53.sl.home (Scott Lurndal) - 2024-09-03 20:34 +0000
Re: Long filenames in DOS/Windows and Unix/Linux (Was: Piping to stdin) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-09-03 21:52 +0000
Re: Long filenames in DOS/Windows and Unix/Linux Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-09-03 15:16 -0700
Re: Long filenames in DOS/Windows and Unix/Linux Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-09-03 22:18 +0000
Re: Long filenames in DOS/Windows and Unix/Linux scott@slp53.sl.home (Scott Lurndal) - 2024-09-03 22:59 +0000
Re: Long filenames in DOS/Windows and Unix/Linux Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-09-03 16:10 -0700
Re: Long filenames in DOS/Windows and Unix/Linux Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-09-03 23:54 +0000
Re: Long filenames in DOS/Windows and Unix/Linux Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-09-03 17:27 -0700
Re: Long filenames in DOS/Windows and Unix/Linux Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-09-04 00:44 +0000
Re: Long filenames in DOS/Windows and Unix/Linux Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-09-03 21:36 -0700
Re: Long filenames in DOS/Windows and Unix/Linux Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-09-04 07:05 +0000
Re: Long filenames in DOS/Windows and Unix/Linux Ralf Fassel <ralfixx@gmx.de> - 2024-09-04 11:47 +0200
Re: Long filenames in DOS/Windows and Unix/Linux Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-09-04 03:44 -0700
Re: Long filenames in DOS/Windows and Unix/Linux Nuno Silva <nunojsilva@invalid.invalid> - 2024-09-04 13:33 +0100
Always use "--" (Was: Long filenames in DOS/Windows and Unix/Linux) gazelle@shell.xmission.com (Kenny McCormack) - 2024-09-04 13:04 +0000
Re: Always use "--" (Was: Long filenames in DOS/Windows and Unix/Linux) Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2024-09-04 13:17 +0000
Re: Always use "--" (Was: Long filenames in DOS/Windows and Unix/Linux) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-09-04 21:35 +0000
Re: Always use "--" (Was: Long filenames in DOS/Windows and Unix/Linux) Kaz Kylheku <643-408-1753@kylheku.com> - 2024-09-05 02:29 +0000
Re: Always use "--" (Was: Long filenames in DOS/Windows and Unix/Linux) Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2024-09-05 14:48 +0000
Re: Long filenames in DOS/Windows and Unix/Linux Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-09-03 17:35 -0700
Re: Long filenames in DOS/Windows and Unix/Linux Kaz Kylheku <643-408-1753@kylheku.com> - 2024-09-03 23:15 +0000
Re: Long filenames in DOS/Windows and Unix/Linux Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-09-03 16:38 -0700
Re: Long filenames in DOS/Windows and Unix/Linux Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-09-03 23:56 +0000
Re: Long filenames in DOS/Windows and Unix/Linux Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-09-03 17:19 -0700
Re: Long filenames in DOS/Windows and Unix/Linux Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-09-04 00:41 +0000
Re: Long filenames in DOS/Windows and Unix/Linux Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-09-03 21:29 -0700
Re: Long filenames in DOS/Windows and Unix/Linux Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-09-04 06:49 +0000
Re: Long filenames in DOS/Windows and Unix/Linux Nuno Silva <nunojsilva@invalid.invalid> - 2024-09-04 10:16 +0100
Re: Long filenames in DOS/Windows and Unix/Linux Kaz Kylheku <643-408-1753@kylheku.com> - 2024-09-04 14:30 +0000
Re: Long filenames in DOS/Windows and Unix/Linux John Ames <commodorejohn@gmail.com> - 2024-09-04 08:41 -0700
Re: Long filenames in DOS/Windows and Unix/Linux Muttley@dastardlyhq.com - 2024-09-04 15:57 +0000
Re: Long filenames in DOS/Windows and Unix/Linux Richard Kettlewell <invalid@invalid.invalid> - 2024-09-04 18:03 +0100
Re: Long filenames in DOS/Windows and Unix/Linux Ralf Fassel <ralfixx@gmx.de> - 2024-09-05 11:29 +0200
Re: Long filenames in DOS/Windows and Unix/Linux Richard Kettlewell <invalid@invalid.invalid> - 2024-09-05 18:21 +0100
Re: Long filenames in DOS/Windows and Unix/Linux candycanearter07 <candycanearter07@candycanearter07.nomail.afraid> - 2024-09-07 18:20 +0000
Word splitting oddities (Was: Long filenames in DOS/Windows and Unix/Linux) gazelle@shell.xmission.com (Kenny McCormack) - 2024-09-07 21:51 +0000
Re: Long filenames in DOS/Windows and Unix/Linux Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-09-10 07:17 +0200
Re: Long filenames in DOS/Windows and Unix/Linux (Was: Piping to stdin) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-09-10 06:51 +0200
Re: Long filenames in DOS/Windows and Unix/Linux (Was: Piping to Muttley@dastardlyhq.com - 2024-09-04 07:31 +0000
Re: Long filenames in DOS/Windows and Unix/Linux (Was: Piping to stdin) Marcel Mueller <news.5.maazl@spamgourmet.org> - 2024-09-01 11:44 +0200
Re: Piping to stdin Phil Carmody <pc+usenet@asdf.org> - 2023-08-15 23:24 +0300
Re: Piping to stdin Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2023-08-15 20:50 +0000
Re: Piping to stdin Phil Carmody <pc+usenet@asdf.org> - 2023-08-16 17:11 +0300
Re: Piping to stdin Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2023-08-16 15:25 +0000
Re: Piping to stdin Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-16 19:29 +0000
Re: Piping to stdin Phil Carmody <pc+usenet@asdf.org> - 2023-08-17 14:49 +0300
Re: Piping to stdin Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-16 03:20 +0100
Re: Piping to stdin Phil Carmody <pc+usenet@asdf.org> - 2023-08-15 18:33 +0300
Re: Piping to stdin "Nuno Silva" <nunojsilva@invalid.invalid> - 2023-08-14 09:45 +0100
Re: Piping to stdin Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2023-08-13 21:26 -0600
Re: Piping to stdin Spiros Bousbouras <spibou@gmail.com> - 2023-08-14 09:24 +0000
Re: Piping to stdin Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-14 11:29 +0100
Re: Piping to stdin gazelle@shell.xmission.com (Kenny McCormack) - 2023-08-14 11:28 +0000
Re: Piping to stdin scott@slp53.sl.home (Scott Lurndal) - 2023-08-14 15:41 +0000
Re: Piping to stdin Richard Harnden <richard.nospam@gmail.com> - 2023-08-14 22:02 +0100
Re: Piping to stdin scott@slp53.sl.home (Scott Lurndal) - 2023-08-14 21:14 +0000
Page 6 of 8 — ← Prev page 1 2 3 4 5 [6] 7 8 Next page →
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2024-09-03 16:10 -0700 |
| Subject | Re: Long filenames in DOS/Windows and Unix/Linux |
| Message-ID | <87o7541ggd.fsf@nosuchdomain.example.com> |
| In reply to | #16270 |
Lawrence D'Oliveiro <ldo@nz.invalid> writes:
> On Tue, 03 Sep 2024 15:16:36 -0700, Keith Thompson wrote:
>> For example, I might type something like:
>>
>> for file in * ; do cp -p $file $file.bak ; done
>
> It’s quite easy to fix that to work with spaces in file names.
I wouldn't call it "quite easy". Certainly it can be done, and I do it
when I need to. My point is that there is an advantage in being able to
avoid the extra effort when I know it's not needed.
How would you do it?
> How long
> have you been working with *nix shells?
A long time. I might consider being more specific later.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2024-09-03 23:54 +0000 |
| Subject | Re: Long filenames in DOS/Windows and Unix/Linux |
| Message-ID | <vb87jr$3h6uk$1@dont-email.me> |
| In reply to | #16272 |
On Tue, 03 Sep 2024 16:10:42 -0700, Keith Thompson wrote:
> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>
>> On Tue, 03 Sep 2024 15:16:36 -0700, Keith Thompson wrote:
>>>
>>> For example, I might type something like:
>>>
>>> for file in * ; do cp -p $file $file.bak ; done
>>
>> It’s quite easy to fix that to work with spaces in file names.
>
> I wouldn't call it "quite easy".
As easy as this, in Bash at least:
IFS=$'\n'
I’ve been told elsewhere that $'\n' is also valid in the latest Posix
spec.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2024-09-03 17:27 -0700 |
| Subject | Re: Long filenames in DOS/Windows and Unix/Linux |
| Message-ID | <87bk141cw9.fsf@nosuchdomain.example.com> |
| In reply to | #16275 |
Lawrence D'Oliveiro <ldo@nz.invalid> writes:
> On Tue, 03 Sep 2024 16:10:42 -0700, Keith Thompson wrote:
>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>> On Tue, 03 Sep 2024 15:16:36 -0700, Keith Thompson wrote:
>>>> For example, I might type something like:
>>>>
>>>> for file in * ; do cp -p $file $file.bak ; done
>>>
>>> It’s quite easy to fix that to work with spaces in file names.
>>
>> I wouldn't call it "quite easy".
>
> As easy as this, in Bash at least:
>
> IFS=$'\n'
>
> I’ve been told elsewhere that $'\n' is also valid in the latest Posix
> spec.
Not bad -- but of course that's not all you have to do.
I tried it just now. My first attempt was
IFS='\n' for file in * ; do cp -p $file $file.bak ; done
but that's a syntax error ("for" is a shell keyword, not a command).
Second attempt:
IFS='\n' ; for file in * ; do cp -p $file $file.bak ; done
but that leaves IFS set to its new value in my interactive shell.
Either of these seems to work:
( IFS='\n' ; for file in * ; do cp -p $file $file.bak ; done )
{ IFS='\n' ; for file in * ; do cp -p $file $file.bak ; done }
That's still more trouble than it's worth *for me*. It handles
99+% of real-world cases, but I expect it would fail if a file had
a newline in its name. (Actually a quick experiment indicates that
that seems to work. I don't know how or why.) I have other ways of
handling this kind of thing if I need 100% reliability regardless of
any funny characters in file names (Perl, readdir). And the simple
"for file in *" handles 99% of the cases that I personally have to
deal with.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2024-09-04 00:44 +0000 |
| Subject | Re: Long filenames in DOS/Windows and Unix/Linux |
| Message-ID | <vb8ahn$3hhg4$2@dont-email.me> |
| In reply to | #16278 |
On Tue, 03 Sep 2024 17:27:34 -0700, Keith Thompson wrote: > Second attempt: > > IFS='\n' ; for file in * ; do cp -p $file $file.bak ; done > > but that leaves IFS set to its new value in my interactive shell. Which in my experience is no biggie. Next step: what if you wanted to handle newlines in file names as well?
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2024-09-03 21:36 -0700 |
| Subject | Re: Long filenames in DOS/Windows and Unix/Linux |
| Message-ID | <8734mg11cv.fsf@nosuchdomain.example.com> |
| In reply to | #16281 |
Lawrence D'Oliveiro <ldo@nz.invalid> writes:
> On Tue, 03 Sep 2024 17:27:34 -0700, Keith Thompson wrote:
>> Second attempt:
>>
>> IFS='\n' ; for file in * ; do cp -p $file $file.bak ; done
>>
>> but that leaves IFS set to its new value in my interactive shell.
>
> Which in my experience is no biggie.
Perhaps. Honestly, I've never paid enough attention to IFS to have any
confidence in doing anything other than leaving it alone.
> Next step: what if you wanted to handle newlines in file names as well?
Either `find ... -print0 | xargs -0 ...` or a quick Perl script.
opendir my $DIR, '.' or die ".: $!\n";
foreach my $file(grep { $_ ne '.' and $_ ne '..' } readdir $DIR) {
system 'cp', '-p', $file, "$file.bak";
# error checking omitted for now
}
closedir $DIR;
(I'm not arguing that Perl is the best or only language for this; it
just happens to be what I'm most familiar with.)
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2024-09-04 07:05 +0000 |
| Subject | Re: Long filenames in DOS/Windows and Unix/Linux |
| Message-ID | <vb90s2$3o2de$1@dont-email.me> |
| In reply to | #16283 |
On Tue, 03 Sep 2024 21:36:48 -0700, Keith Thompson wrote:
> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>
>> Next step: what if you wanted to handle newlines in file names as well?
>
> Either `find ... -print0 | xargs -0 ...` or a quick Perl script.
Sure, it’s much easier in Perl or Python or some other such programming-
oriented (as opposed to command-oriented) language. But it can be done in
Bash.
The thing is, while find is handy for getting the matching file names,
xargs is not always the most convenient way of processing them. You often
just want to be able to do “for f in «filenames»; do «whatever» done”,
e.g.:
collect_expand «wildcard» found_filenames
for f in "${found_filenames[@]}"; do
echo "found" $(printf %q "$f")
done
That “collect_expand” is a Bash function. Do you want to figure out how to
write it, before I post my solution? ;)
[toc] | [prev] | [next] | [standalone]
| From | Ralf Fassel <ralfixx@gmx.de> |
|---|---|
| Date | 2024-09-04 11:47 +0200 |
| Subject | Re: Long filenames in DOS/Windows and Unix/Linux |
| Message-ID | <yga34mfoily.fsf@akutech.de> |
| In reply to | #16275 |
* Lawrence D'Oliveiro <ldo@nz.invalid> | On Tue, 03 Sep 2024 16:10:42 -0700, Keith Thompson wrote: > | > Lawrence D'Oliveiro <ldo@nz.invalid> writes: | >> | >> On Tue, 03 Sep 2024 15:16:36 -0700, Keith Thompson wrote: | >>> | >>> For example, I might type something like: | >>> | >>> for file in * ; do cp -p $file $file.bak ; done | >> | >> It’s quite easy to fix that to work with spaces in file names. | > | > I wouldn't call it "quite easy". > | As easy as this, in Bash at least: > | IFS=$'\n' Forgive my ignorance, but what is wrong with for file in * ; do cp -p "$file" "$file.bak" ; done ? Works for both spaces and newlines in file names... (at least with bash and ksh). R'
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2024-09-04 03:44 -0700 |
| Subject | Re: Long filenames in DOS/Windows and Unix/Linux |
| Message-ID | <87ttevzoj3.fsf@nosuchdomain.example.com> |
| In reply to | #16290 |
Ralf Fassel <ralfixx@gmx.de> writes:
> * Lawrence D'Oliveiro <ldo@nz.invalid>
> | On Tue, 03 Sep 2024 16:10:42 -0700, Keith Thompson wrote:
>>
> | > Lawrence D'Oliveiro <ldo@nz.invalid> writes:
> | >>
> | >> On Tue, 03 Sep 2024 15:16:36 -0700, Keith Thompson wrote:
> | >>>
> | >>> For example, I might type something like:
> | >>>
> | >>> for file in * ; do cp -p $file $file.bak ; done
> | >>
> | >> It’s quite easy to fix that to work with spaces in file names.
> | >
> | > I wouldn't call it "quite easy".
>>
> | As easy as this, in Bash at least:
>>
> | IFS=$'\n'
>
> Forgive my ignorance, but what is wrong with
>
> for file in * ; do cp -p "$file" "$file.bak" ; done
>
> ? Works for both spaces and newlines in file names... (at least with
> bash and ksh).
You're absolutely right. I'm not sure how I missed that. (I was
thinking that * just expands to a string, but that's obviously not the
case.)
D'oh!
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Nuno Silva <nunojsilva@invalid.invalid> |
|---|---|
| Date | 2024-09-04 13:33 +0100 |
| Subject | Re: Long filenames in DOS/Windows and Unix/Linux |
| Message-ID | <vb9k2l$3r705$1@dont-email.me> |
| In reply to | #16291 |
On 2024-09-04, Keith Thompson wrote: > Ralf Fassel <ralfixx@gmx.de> writes: >> * Lawrence D'Oliveiro <ldo@nz.invalid> >> | On Tue, 03 Sep 2024 16:10:42 -0700, Keith Thompson wrote: >>> >> | > Lawrence D'Oliveiro <ldo@nz.invalid> writes: >> | >> >> | >> On Tue, 03 Sep 2024 15:16:36 -0700, Keith Thompson wrote: >> | >>> >> | >>> For example, I might type something like: >> | >>> >> | >>> for file in * ; do cp -p $file $file.bak ; done >> | >> >> | >> It’s quite easy to fix that to work with spaces in file names. >> | > >> | > I wouldn't call it "quite easy". >>> >> | As easy as this, in Bash at least: >>> >> | IFS=$'\n' >> >> Forgive my ignorance, but what is wrong with >> >> for file in * ; do cp -p "$file" "$file.bak" ; done >> >> ? Works for both spaces and newlines in file names... (at least with >> bash and ksh). > > You're absolutely right. I'm not sure how I missed that. (I was > thinking that * just expands to a string, but that's obviously not the > case.) > > D'oh! (Along with these quotes, I'd add ./ before $file.) -- Nuno Silva
[toc] | [prev] | [next] | [standalone]
| From | gazelle@shell.xmission.com (Kenny McCormack) |
|---|---|
| Date | 2024-09-04 13:04 +0000 |
| Subject | Always use "--" (Was: Long filenames in DOS/Windows and Unix/Linux) |
| Message-ID | <vb9ls7$1igeo$1@news.xmission.com> |
| In reply to | #16293 |
In article <vb9k2l$3r705$1@dont-email.me>,
Nuno Silva <nunojsilva@invalid.invalid> wrote:
...
>> D'oh!
>
>(Along with these quotes, I'd add ./ before $file.)
Or, more simply, just put -- after the -p.
This is an often overlooked aspect of shell programing. You should always
use "--". The "shellcheck" program will tell you this, if you let it.
--
"Women should not be enlightened or educated in any way. They should be
segregated because they are the cause of unholy erections in holy men.
-- Saint Augustine (354-430) --
[toc] | [prev] | [next] | [standalone]
| From | Lew Pitcher <lew.pitcher@digitalfreehold.ca> |
|---|---|
| Date | 2024-09-04 13:17 +0000 |
| Subject | Re: Always use "--" (Was: Long filenames in DOS/Windows and Unix/Linux) |
| Message-ID | <vb9mls$3rk17$1@dont-email.me> |
| In reply to | #16294 |
On Wed, 04 Sep 2024 13:04:07 +0000, Kenny McCormack wrote: > In article <vb9k2l$3r705$1@dont-email.me>, > Nuno Silva <nunojsilva@invalid.invalid> wrote: > ... >>> D'oh! >> >>(Along with these quotes, I'd add ./ before $file.) > > Or, more simply, just put -- after the -p. > > This is an often overlooked aspect of shell programing. You should always > use "--". The "shellcheck" program will tell you this, if you let it. The "--" option is just that, an option coded into the argument parser of the program being invoked. Many programs /do not/ recognize "--" as an "end of flags" argument, so the effectiveness of "--" is unreliable. OTOH, if you specify a fully qualified pathname, (or, at least, a qualified relative pathname), you can assure yourself that the file path provided to the program /will not/ start with the '-' that indicates a program flag. Note that all this is /convention/ and not /requirement/. There are situations in which /none/ of the above applies, as a) the program interprets it's arguments by /position/, or b) the program doesn't use the '-' to introduce flag arguments, or c) the program doesn't take filenames as arguments, or d) some other conditions that I'm too lazy to enumerate HTH -- Lew Pitcher "In Skills We Trust"
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2024-09-04 21:35 +0000 |
| Subject | Re: Always use "--" (Was: Long filenames in DOS/Windows and Unix/Linux) |
| Message-ID | <vbajqa$3a4$1@dont-email.me> |
| In reply to | #16296 |
On Wed, 4 Sep 2024 13:17:48 -0000 (UTC), Lew Pitcher wrote: > The "--" option is just that, an option coded into the argument parser > of the program being invoked. Many programs /do not/ recognize "--" as > an "end of flags" argument, so the effectiveness of "--" is unreliable. All the good ones do. This is why getopt(3) with POSIXLY_CORRECT stops looking for options as soon as a nonoption argument is encountered. Remember also that arguments need not necessarily be file names, so prefixing them all with “./” willy-nilly may not produce the right result anyway.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <643-408-1753@kylheku.com> |
|---|---|
| Date | 2024-09-05 02:29 +0000 |
| Subject | Re: Always use "--" (Was: Long filenames in DOS/Windows and Unix/Linux) |
| Message-ID | <20240904192549.23@kylheku.com> |
| In reply to | #16296 |
On 2024-09-04, Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote: > On Wed, 04 Sep 2024 13:04:07 +0000, Kenny McCormack wrote: > >> In article <vb9k2l$3r705$1@dont-email.me>, >> Nuno Silva <nunojsilva@invalid.invalid> wrote: >> ... >>>> D'oh! >>> >>>(Along with these quotes, I'd add ./ before $file.) >> >> Or, more simply, just put -- after the -p. >> >> This is an often overlooked aspect of shell programing. You should always >> use "--". The "shellcheck" program will tell you this, if you let it. > > The "--" option is just that, an option coded into the argument parser of > the program being invoked. Many programs /do not/ recognize "--" as an > "end of flags" argument, so the effectiveness of "--" is unreliable. > > OTOH, if you specify a fully qualified pathname, (or, at least, a qualified > relative pathname), you can assure yourself that the file path provided > to the program /will not/ start with the '-' that indicates a program flag. > > Note that all this is /convention/ and not /requirement/. There are situations > in which /none/ of the above applies, as > a) the program interprets it's arguments by /position/, or > b) the program doesn't use the '-' to introduce flag arguments, or > c) the program doesn't take filenames as arguments, or > d) some other conditions that I'm too lazy to enumerate d) it's a goddamned GNU program that continues to take options after non-option arguments! $ ls . -ld drwxr-xr-x 67 kaz kaz 36864 Sep 3 15:59 . ... unless -- is specified to signal the end of options. $ ls -ld -- . -ld ls: cannot access '-ld': No such file or directory drwxr-xr-x 67 kaz kaz 36864 Sep 3 15:59 . So unfortunately although starting an argument with ./ will ensure that it's not treated as an option, it doesn't mean it will be treated as the first non-option argument after which there are no more option arguments. -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca
[toc] | [prev] | [next] | [standalone]
| From | Lew Pitcher <lew.pitcher@digitalfreehold.ca> |
|---|---|
| Date | 2024-09-05 14:48 +0000 |
| Subject | Re: Always use "--" (Was: Long filenames in DOS/Windows and Unix/Linux) |
| Message-ID | <vbcgbu$cc45$1@dont-email.me> |
| In reply to | #16302 |
On Thu, 05 Sep 2024 02:29:49 +0000, Kaz Kylheku wrote: > On 2024-09-04, Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote: >> On Wed, 04 Sep 2024 13:04:07 +0000, Kenny McCormack wrote: >> >>> In article <vb9k2l$3r705$1@dont-email.me>, >>> Nuno Silva <nunojsilva@invalid.invalid> wrote: >>> ... >>>>> D'oh! >>>> >>>>(Along with these quotes, I'd add ./ before $file.) >>> >>> Or, more simply, just put -- after the -p. >>> >>> This is an often overlooked aspect of shell programing. You should always >>> use "--". The "shellcheck" program will tell you this, if you let it. >> >> The "--" option is just that, an option coded into the argument parser of >> the program being invoked. Many programs /do not/ recognize "--" as an >> "end of flags" argument, so the effectiveness of "--" is unreliable. >> >> OTOH, if you specify a fully qualified pathname, (or, at least, a qualified >> relative pathname), you can assure yourself that the file path provided >> to the program /will not/ start with the '-' that indicates a program flag. >> >> Note that all this is /convention/ and not /requirement/. There are situations >> in which /none/ of the above applies, as >> a) the program interprets it's arguments by /position/, or >> b) the program doesn't use the '-' to introduce flag arguments, or >> c) the program doesn't take filenames as arguments, or >> d) some other conditions that I'm too lazy to enumerate > > d) it's a goddamned GNU program that continues to take options > after non-option arguments! > > $ ls . -ld > drwxr-xr-x 67 kaz kaz 36864 Sep 3 15:59 . > > ... unless -- is specified to signal the end of options. > > $ ls -ld -- . -ld > ls: cannot access '-ld': No such file or directory > drwxr-xr-x 67 kaz kaz 36864 Sep 3 15:59 . > > So unfortunately although starting an argument with ./ will > ensure that it's not treated as an option, it doesn't mean > it will be treated as the first non-option argument after > which there are no more option arguments. That seems to be a symptom of the use of the GNU variant of the POSIX getopt(3) function. "By default, [GNU] getopt() permutes the contents of argv as it scans, so that eventually all the nonoptions are at the end. Two other modes are also implemented. If the first character of optstring is '+' or the envi- ronment variable POSIXLY_CORRECT is set, then option processing stops as soon as a nonoption argument is encountered." The "workaround" seems to be to set the POSIXLY_CORRECT envvar as part of your standard environment. -- Lew Pitcher "In Skills We Trust"
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2024-09-03 17:35 -0700 |
| Subject | Re: Long filenames in DOS/Windows and Unix/Linux |
| Message-ID | <86wmjsntm0.fsf@linuxsc.com> |
| In reply to | #16272 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: > Lawrence D'Oliveiro <ldo@nz.invalid> writes: > >> How long have you been working with *nix shells? > > A long time. [...] My answer is not very long; less than 50 years.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <643-408-1753@kylheku.com> |
|---|---|
| Date | 2024-09-03 23:15 +0000 |
| Subject | Re: Long filenames in DOS/Windows and Unix/Linux |
| Message-ID | <20240903155649.659@kylheku.com> |
| In reply to | #16269 |
On 2024-09-03, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: > John Ames <commodorejohn@gmail.com> writes: >> On Tue, 3 Sep 2024 20:11:28 -0000 (UTC) >> Kaz Kylheku <643-408-1753@kylheku.com> wrote: >> >>> Because it is based on a strawman interpretation of the "no spaces" >>> rule. That strawman interpretation is that there are no other rules >>> used in combination with the "no spaces" rule, and thus that any >>> ridiculous name is fine, just as long as it doesn't contain spaces. >>> >>> And so, look how unreadable is this 100 character name in CamelCase! >>> Q.E.D. no spaces is a bad recommendation! >> >> Well, there were no other factors *presented* alongside the blanket >> statement that spaces in filenames are unnecessary, so it would appear >> on the face of it to be an accurate assessment of the claim being made, >> which wasn't in a post of yours to begin with. >> >> And I'd still like to know who died and made whom king where filenames >> and spaces therein are concrned. > > There is no official "rule" about spaces in filenames, though I can > imagine easily imagine that some organizations and projects have > rules forbidding them. A couple of data points: The gcc git repo > contains 137394 files and none of them have spaces in their names. The GCC project is Makefile-based. The make utility has no support for paths with spaces. Use of make is a great repellant against spaces in names. If a make variable contains spaces, there is no way to quote it within make. There is no way to express a prerequisite or target name with spaces. GNU Make text processing constructs like $(foreach ...) don't deal with spaces; there is no way for them to identify items that contain spaces. > The Linux kernel git repo contains 85803 files, and exactly one has > spaces in its name. You can bet it's one that's not referenced in any Makefile. > Spaces in file names are likely not to be an issue if you interact > with the filesystem via a GUI like Windows Explorer *or* if you use > a scripting language like Perl or Python that requires strings used > as filenames to be enclosed in quotation marks. In those contexts, > space is just another character. The buffoons that use spaces in document names in GUIs will find some way to confuse themselves, like typing two spaces instead of one, or quoting names to each other in e-mails without enough delimitation or use of typeface to know which words are part of the name and which are surrounding text. E.g. A: "Can you send the file analysis and report to me?" B: "I will report to you, but I can't find the file analysis." A: "No, the file is called analysis and report. :) Send that to me." If you follow the convention that name of a file is one word that contains no leading or trailing punctuation, then you can use it in written sentences without ambiguity or quotes around it. You can put a period or comma after it, and know that it can't be part of the name since it would constitute trailing punctuation. -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2024-09-03 16:38 -0700 |
| Subject | Re: Long filenames in DOS/Windows and Unix/Linux |
| Message-ID | <87jzfs1f6p.fsf@nosuchdomain.example.com> |
| In reply to | #16273 |
Kaz Kylheku <643-408-1753@kylheku.com> writes:
[...]
> The make utility has no support for paths with spaces.
Looks like you're right. This bug report is 22 years old:
https://savannah.gnu.org/bugs/?712
I'm mildly amused by the fact that I've never noticed this before.
[snip]
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2024-09-03 23:56 +0000 |
| Subject | Re: Long filenames in DOS/Windows and Unix/Linux |
| Message-ID | <vb87o7$3h6uk$2@dont-email.me> |
| In reply to | #16274 |
On Tue, 03 Sep 2024 16:38:06 -0700, Keith Thompson wrote:
>> The make utility has no support for paths with spaces.
>
> Looks like you're right.
I have some Makefiles with spaces in the dependency names, of the form:
target\ name\ with\ space : source\ name\ with\ space
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2024-09-03 17:19 -0700 |
| Subject | Re: Long filenames in DOS/Windows and Unix/Linux |
| Message-ID | <87frqg1da2.fsf@nosuchdomain.example.com> |
| In reply to | #16276 |
Lawrence D'Oliveiro <ldo@nz.invalid> writes:
> On Tue, 03 Sep 2024 16:38:06 -0700, Keith Thompson wrote:
>>> The make utility has no support for paths with spaces.
>>
>> Looks like you're right.
>
> I have some Makefiles with spaces in the dependency names, of the form:
>
> target\ name\ with\ space : source\ name\ with\ space
I'd be interested in knowing how you do that.
$ cat Makefile
foo\ bar: foo\ bar.c
$ make
cc foo bar.c -o foo bar
cc: fatal error: input file ‘foo’ is the same as output file
compilation terminated.
make: *** [<builtin>: foo bar] Error 1
$
I'm using GNU Make 4.3.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2024-09-04 00:41 +0000 |
| Subject | Re: Long filenames in DOS/Windows and Unix/Linux |
| Message-ID | <vb8aci$3hhg4$1@dont-email.me> |
| In reply to | #16277 |
On Tue, 03 Sep 2024 17:19:17 -0700, Keith Thompson wrote: > Lawrence D'Oliveiro <ldo@nz.invalid> writes: > >> I have some Makefiles with spaces in the dependency names, of the form: >> >> target\ name\ with\ space : source\ name\ with\ space > > I'd be interested in knowing how you do that. > > $ cat Makefile foo\ bar: foo\ bar.c > $ make cc foo bar.c -o foo bar > cc: fatal error: input file ‘foo’ is the same as output file > compilation terminated. The Makefiles in question are not using the default build rules for C code: they are building other things, with explicit use of the "$<" and "$@" variable substitutions.
[toc] | [prev] | [next] | [standalone]
Page 6 of 8 — ← Prev page 1 2 3 4 5 [6] 7 8 Next page →
Back to top | Article view | comp.unix.programmer
csiph-web