- Original Message -
From: "Sean Hunter" <[EMAIL PROTECTED]>
To: "Thorsten Glaser Geuer" <[EMAIL PROTECTED]>
Sent: Thursday, 8. March 2001 13:01
Subject: Re: binfmt_script and ^M
> On Tue, Mar 06, 2001 at 09:10:26PM -, Thorsten Glaser Geue
- Original Message -
From: "Sean Hunter" [EMAIL PROTECTED]
To: "Thorsten Glaser Geuer" [EMAIL PROTECTED]
Sent: Thursday, 8. March 2001 13:01
Subject: Re: binfmt_script and ^M
On Tue, Mar 06, 2001 at 09:10:26PM -, Thorsten Glaser Geuer wrote:
- Original M
Sean Hunter <[EMAIL PROTECTED]> writes:
> I propose
>
>/proc/sys/kernel/im_too_lame_to_learn_how_to_use_the_most_basic_of_unix_tools_so_i_want_the_kernel_to_be_filled_with_crap_to_disguise_my_ineptitude
Well, too me it seems that you are intolerant.
I think that it should not be added to
Sean Hunter [EMAIL PROTECTED] writes:
I propose
/proc/sys/kernel/im_too_lame_to_learn_how_to_use_the_most_basic_of_unix_tools_so_i_want_the_kernel_to_be_filled_with_crap_to_disguise_my_ineptitude
Well, too me it seems that you are intolerant.
I think that it should not be added to kernel
- Original Message -
From: "David Weinehall" <[EMAIL PROTECTED]>
To: "Sean Hunter" <[EMAIL PROTECTED]>; "Laramie Leavitt"
<[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Tuesday, 6. March 2001 15:37
Subject: Re: binfmt_script and
On Tue, 6 Mar 2001, Peter Samuelson wrote:
> [Dr. Kelsey Hudson]
> > umm, last i checked a carriage return wasn't whitespace... space,
> > horizontal tab, vertical tab, form feed constitute whitespace IIRC...
>
> Where and when did you check? Several sources disagree with you.
a long while
- Original Message -
From: "Jesse Pollard" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; "Richard B. Johnson" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Monday, 5. March 2001 19:14
Subject: Re: binfmt_script and
John Kodis <[EMAIL PROTECTED]> writes:
|> On Tue, Mar 06, 2001 at 11:36:29AM -0700, Jeff Coy wrote:
|>
|> > '#!/usr/bin/perl -w^M' works without any special handling; the link is
|> > not needed:
|>
|> This is the main reason that I think that the kernel should treat \r
|> as just another
On Tue, Mar 06, 2001 at 11:36:29AM -0700, Jeff Coy wrote:
> '#!/usr/bin/perl -w^M' works without any special handling; the link is
> not needed:
This is the main reason that I think that the kernel should treat \r
as just another whitespace character: it's what most shells do, it's
what most
On Tue, 6 Mar 2001, Peter Samuelson wrote:
>
> [Jeff Coy]
> > this issue came up frequently with customers uploading scripts in
> > binary mode trying to run #!/usr/bin/perl^M. The solution for me was
> > to just do the following:
> >
> > cd /usr/bin
> > sudo ln -s perl^V^M perl
>
>
[Dr. Kelsey Hudson]
> umm, last i checked a carriage return wasn't whitespace... space,
> horizontal tab, vertical tab, form feed constitute whitespace IIRC...
Where and when did you check? Several sources disagree with you.
Peter
-
To unsubscribe from this list: send the line "unsubscribe
Paul-
Minor historical note. The `#!' processing was never done by the
shell, this was always done in the kernel. Think about about it,
the `#' character denotes a comment line, the shell ignores that
line. `#!' was used to create a way for the kernel to execute
a shell script directly.
[Jeff Coy]
> this issue came up frequently with customers uploading scripts in
> binary mode trying to run #!/usr/bin/perl^M. The solution for me was
> to just do the following:
>
> cd /usr/bin
> sudo ln -s perl^V^M perl
So none of your customers tried '#!/usr/bin/perl -w^M'?
Wouldn't it be easier to run the script interpreter through WINE ? This
way we could workaround several Win32 peculiarities, and users wouldn't
bother taking special steps when coding on their home PC.
Xav
Le 06 Mar 2001 15:12:42 +, Sean Hunter a écrit :
>
> I propose
>
- Received message begins Here -
>
> Jesse Pollard <[EMAIL PROTECTED]> writes:
>
> |> Andreas Schwab <[EMAIL PROTECTED]>:Andreas Schwab <[EMAIL PROTECTED]>Andreas Schwab
><[EMAIL PROTECTED]>
> |> > Paul Flinders <[EMAIL PROTECTED]> writes:
> |> >
> |> > |> Andreas Schwab
On Tue, 6 Mar 2001, Sean Hunter wrote:
>
> I propose
>
>/proc/sys/kernel/im_too_lame_to_learn_how_to_use_the_most_basic_of_unix_tools_so_i_want_the_kernel_to_be_filled_with_crap_to_disguise_my_ineptitude
>
> Any support?
Hrm - make it part of the "fscking_moron" subsystem.
On Tue, Mar 06, 2001 at 03:12:42PM +, Sean Hunter wrote:
>
> I propose
>
>/proc/sys/kernel/im_too_lame_to_learn_how_to_use_the_most_basic_of_unix_tools_so_i_want_the_kernel_to_be_filled_with_crap_to_disguise_my_ineptitude
>
> Any support?
Hey, let's go even further! Let's add support in
I propose
/proc/sys/kernel/im_too_lame_to_learn_how_to_use_the_most_basic_of_unix_tools_so_i_want_the_kernel_to_be_filled_with_crap_to_disguise_my_ineptitude
Any support?
Sean
On Tue, Mar 06, 2001 at 02:45:51PM -, Laramie Leavitt wrote:
> > Andreas Schwab wrote:
> > > Paul Flinders
On Mon, 5 Mar 2001, Robert Read wrote:
> And isspace('\n') is also true. At question here is not the
> definition of whitespace. The question is, what is the definition of
> a command line? What characters are valid command line seperators?
>
It doesn't seem likely that '\r' is going to be
Jesse Pollard <[EMAIL PROTECTED]> writes:
|> Andreas Schwab <[EMAIL PROTECTED]>:Andreas Schwab <[EMAIL PROTECTED]>Andreas Schwab
|<[EMAIL PROTECTED]>
|> > Paul Flinders <[EMAIL PROTECTED]> writes:
|> >
|> > |> Andreas Schwab wrote:
|> > |>
|> > |> > This [isspace('\r') == 1] has no
> Andreas Schwab wrote:
> > Paul Flinders <[EMAIL PROTECTED]> writes:
> > |> Andreas Schwab wrote:
> > |>
> > |> > This [isspace('\r') == 1] has no significance here. The
> right thing to
> > |>
> > |> > look at is $IFS, which does not contain \r by default.
> The shell only splits
> > |>
> > |>
Andreas Schwab <[EMAIL PROTECTED]>:Andreas Schwab <[EMAIL PROTECTED]>Andreas Schwab
<[EMAIL PROTECTED]>
> Paul Flinders <[EMAIL PROTECTED]> writes:
>
> |> Andreas Schwab wrote:
> |>
> |> > This [isspace('\r') == 1] has no significance here. The right thing to
> |>
> |> > look at is $IFS,
Andreas Schwab wrote:
> Paul Flinders <[EMAIL PROTECTED]> writes:
>
> |> Andreas Schwab wrote:
> |>
> |> > This [isspace('\r') == 1] has no significance here. The right thing to
> |>
> |> > look at is $IFS, which does not contain \r by default. The shell only splits
> |>
> |> > words by "IFS
Hi!
> > Somebody must have missed the boat entirely. Unix does not, never
> > has, and never will end a text line with '\r'. It's Microsoft junk
> > that does that, a throwback to CP/M, a throwback to MDS/200.
>
> Yes, _we_ all know that. However, it's not really intuitive to the user
> getting
Paul Flinders <[EMAIL PROTECTED]> writes:
|> Andreas Schwab wrote:
|>
|> > This [isspace('\r') == 1] has no significance here. The right thing to
|>
|> > look at is $IFS, which does not contain \r by default. The shell only splits
|>
|> > words by "IFS whitespace", and the kernel should be
Paul Flinders [EMAIL PROTECTED] writes:
| Andreas Schwab wrote:
|
| This [isspace('\r') == 1] has no significance here. The right thing to
|
| look at is $IFS, which does not contain \r by default. The shell only splits
|
| words by "IFS whitespace", and the kernel should be consistent
Hi!
Somebody must have missed the boat entirely. Unix does not, never
has, and never will end a text line with '\r'. It's Microsoft junk
that does that, a throwback to CP/M, a throwback to MDS/200.
Yes, _we_ all know that. However, it's not really intuitive to the user
getting a 'No
Andreas Schwab wrote:
Paul Flinders [EMAIL PROTECTED] writes:
| Andreas Schwab wrote:
|
| This [isspace('\r') == 1] has no significance here. The right thing to
|
| look at is $IFS, which does not contain \r by default. The shell only splits
|
| words by "IFS whitespace", and the
Andreas Schwab [EMAIL PROTECTED]:Andreas Schwab [EMAIL PROTECTED]Andreas Schwab
[EMAIL PROTECTED]
Paul Flinders [EMAIL PROTECTED] writes:
| Andreas Schwab wrote:
|
| This [isspace('\r') == 1] has no significance here. The right thing to
|
| look at is $IFS, which does not contain \r
Andreas Schwab wrote:
Paul Flinders [EMAIL PROTECTED] writes:
| Andreas Schwab wrote:
|
| This [isspace('\r') == 1] has no significance here. The
right thing to
|
| look at is $IFS, which does not contain \r by default.
The shell only splits
|
| words by "IFS whitespace",
Jesse Pollard [EMAIL PROTECTED] writes:
| Andreas Schwab [EMAIL PROTECTED]:Andreas Schwab [EMAIL PROTECTED]Andreas Schwab
|[EMAIL PROTECTED]
| Paul Flinders [EMAIL PROTECTED] writes:
|
| | Andreas Schwab wrote:
| |
| | This [isspace('\r') == 1] has no significance here. The right thing
On Mon, 5 Mar 2001, Robert Read wrote:
And isspace('\n') is also true. At question here is not the
definition of whitespace. The question is, what is the definition of
a command line? What characters are valid command line seperators?
It doesn't seem likely that '\r' is going to be
I propose
/proc/sys/kernel/im_too_lame_to_learn_how_to_use_the_most_basic_of_unix_tools_so_i_want_the_kernel_to_be_filled_with_crap_to_disguise_my_ineptitude
Any support?
Sean
On Tue, Mar 06, 2001 at 02:45:51PM -, Laramie Leavitt wrote:
Andreas Schwab wrote:
Paul Flinders [EMAIL
On Tue, Mar 06, 2001 at 03:12:42PM +, Sean Hunter wrote:
I propose
/proc/sys/kernel/im_too_lame_to_learn_how_to_use_the_most_basic_of_unix_tools_so_i_want_the_kernel_to_be_filled_with_crap_to_disguise_my_ineptitude
Any support?
sarcasm
Hey, let's go even further! Let's add support in
On Tue, 6 Mar 2001, Sean Hunter wrote:
I propose
/proc/sys/kernel/im_too_lame_to_learn_how_to_use_the_most_basic_of_unix_tools_so_i_want_the_kernel_to_be_filled_with_crap_to_disguise_my_ineptitude
Any support?
Hrm - make it part of the "fscking_moron" subsystem.
- Received message begins Here -
Jesse Pollard [EMAIL PROTECTED] writes:
| Andreas Schwab [EMAIL PROTECTED]:Andreas Schwab [EMAIL PROTECTED]Andreas Schwab
[EMAIL PROTECTED]
| Paul Flinders [EMAIL PROTECTED] writes:
|
| | Andreas Schwab wrote:
| |
[snip]
| |
Wouldn't it be easier to run the script interpreter through WINE ? This
way we could workaround several Win32 peculiarities, and users wouldn't
bother taking special steps when coding on their home PC.
Xav
Le 06 Mar 2001 15:12:42 +, Sean Hunter a crit :
I propose
[Jeff Coy]
this issue came up frequently with customers uploading scripts in
binary mode trying to run #!/usr/bin/perl^M. The solution for me was
to just do the following:
cd /usr/bin
sudo ln -s perl^V^M perl
So none of your customers tried '#!/usr/bin/perl -w^M'? (Come on,
[Dr. Kelsey Hudson]
umm, last i checked a carriage return wasn't whitespace... space,
horizontal tab, vertical tab, form feed constitute whitespace IIRC...
Where and when did you check? Several sources disagree with you.
Peter
-
To unsubscribe from this list: send the line "unsubscribe
Paul-
Minor historical note. The `#!' processing was never done by the
shell, this was always done in the kernel. Think about about it,
the `#' character denotes a comment line, the shell ignores that
line. `#!' was used to create a way for the kernel to execute
a shell script directly.
On Tue, 6 Mar 2001, Peter Samuelson wrote:
[Jeff Coy]
this issue came up frequently with customers uploading scripts in
binary mode trying to run #!/usr/bin/perl^M. The solution for me was
to just do the following:
cd /usr/bin
sudo ln -s perl^V^M perl
So none of your
On Tue, Mar 06, 2001 at 11:36:29AM -0700, Jeff Coy wrote:
'#!/usr/bin/perl -w^M' works without any special handling; the link is
not needed:
This is the main reason that I think that the kernel should treat \r
as just another whitespace character: it's what most shells do, it's
what most
John Kodis [EMAIL PROTECTED] writes:
| On Tue, Mar 06, 2001 at 11:36:29AM -0700, Jeff Coy wrote:
|
| '#!/usr/bin/perl -w^M' works without any special handling; the link is
| not needed:
|
| This is the main reason that I think that the kernel should treat \r
| as just another whitespace
- Original Message -
From: "Jesse Pollard" [EMAIL PROTECTED]
To: [EMAIL PROTECTED]; "Richard B. Johnson" [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Monday, 5. March 2001 19:14
Subject: Re: binfmt_script and ^M
John Kodis [EMAIL PROTECTED]:
On Tue, 6 Mar 2001, Peter Samuelson wrote:
[Dr. Kelsey Hudson]
umm, last i checked a carriage return wasn't whitespace... space,
horizontal tab, vertical tab, form feed constitute whitespace IIRC...
Where and when did you check? Several sources disagree with you.
a long while ago... i
- Original Message -
From: "David Weinehall" [EMAIL PROTECTED]
To: "Sean Hunter" [EMAIL PROTECTED]; "Laramie Leavitt"
[EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Tuesday, 6. March 2001 15:37
Subject: Re: binfmt_script and ^M
On Tue, Mar 06, 2001 at 03:12
On Mon, 5 Mar 2001, Robert Read wrote:
> On Mon, Mar 05, 2001 at 07:58:52PM +0100, Pozsar Balazs wrote:
> >
> > And what does POSIX say about "#!/bin/sh\r" ?
> > In other words: should the kernel look for the interpreter between the !
> > and the newline, or [the first space or newline] or the
On Mon, Mar 05, 2001 at 10:05:36PM +0100, Pozsar Balazs wrote:
> On Mon, 5 Mar 2001, Robert Read wrote:
> > On Mon, Mar 05, 2001 at 07:58:52PM +0100, Pozsar Balazs wrote:
> > >
> > > And what does POSIX say about "#!/bin/sh\r" ?
> > > In other words: should the kernel look for the interpreter
On Mon, 5 Mar 2001, John Kodis wrote:
> On Mon, Mar 05, 2001 at 08:40:22AM -0500, Richard B. Johnson wrote:
>
> > Somebody must have missed the boat entirely. Unix does not, never
> > has, and never will end a text line with '\r'.
>
> Unix does not, never has, and never will end a text line
> And what does POSIX say about "#!/bin/sh\r" ?
Nothing at all. The #! construction is not part of any standard
right now. The implementation is messy - different operating systems
do vaguely similar things, but all details differ.
Linux can do whatever it wants.
Of course it helps portability
On Mon, 5 Mar 2001, Robert Read wrote:
> On Mon, Mar 05, 2001 at 07:58:52PM +0100, Pozsar Balazs wrote:
> >
> > And what does POSIX say about "#!/bin/sh\r" ?
> > In other words: should the kernel look for the interpreter between the !
> > and the newline, or [the first space or newline] or the
On Mon, Mar 05, 2001 at 07:58:52PM +0100, Pozsar Balazs wrote:
>
> And what does POSIX say about "#!/bin/sh\r" ?
> In other words: should the kernel look for the interpreter between the !
> and the newline, or [the first space or newline] or the first whitespace?
>
> IMHO, the first whitespace.
"Richard B. Johnson" <[EMAIL PROTECTED]> writes:
> No. I did not miss the point. The 'No such file or directory' error
> (when you can see the ^$^$)#@@*& filename with 'ls'), usually means
> that there is something wrong with the file.
Now, let's see. When this error happens, it can be one of
Paul Flinders wrote:
> uses space (0x20) and tab (0x8) as white space and no other character.
>
I mean, of course, tab (_0x9_)
I just checked - the kernel isspace() macro says that \r is whitespace.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
Andreas Schwab wrote:
> This [isspace('\r') == 1] has no significance here. The right thing to
> look at is $IFS, which does not contain \r by default. The shell only splits
> words by "IFS whitespace", and the kernel should be consistent with it:
>
> $ echo -e 'ls foo\r' | sh
> ls: foo: No
John Kodis <[EMAIL PROTECTED]>:
> On Mon, Mar 05, 2001 at 08:40:22AM -0500, Richard B. Johnson wrote:
>
> > Somebody must have missed the boat entirely. Unix does not, never
> > has, and never will end a text line with '\r'.
>
> Unix does not, never has, and never will end a text line with ' '
On Mon, 5 Mar 2001, Paul Flinders wrote:
> Jeff Mcadams wrote:
>
> > Also sprach Rik van Riel
> > >On Mon, 5 Mar 2001, John Kodis wrote:
> > >> On Mon, Mar 05, 2001 at 08:40:22AM -0500, Richard B. Johnson wrote:
> > >> > Somebody must have missed the boat entirely. Unix does not, never
> > >> >
Paul Flinders <[EMAIL PROTECTED]> writes:
|> Jeff Mcadams wrote:
|>
|> > Also sprach Rik van Riel
|> > >On Mon, 5 Mar 2001, John Kodis wrote:
|> > >> On Mon, Mar 05, 2001 at 08:40:22AM -0500, Richard B. Johnson wrote:
|> > >> > Somebody must have missed the boat entirely. Unix does not, never
Followup to: <[EMAIL PROTECTED]>
By author:"Richard B. Johnson" <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
>
> The '\r' (^R) definitely has special significance to Unix. It's called
> "VREPRINT", in the termios structure member "c_cc".
>
'\r' is ^M, not ^R.
> There is really no
On Mon, Mar 05, 2001 at 08:40:22AM -0500, Richard B. Johnson wrote:
> On 5 Mar 2001, Jan Nieuwenhuizen wrote:
> > Pavel Machek <[EMAIL PROTECTED]> writes:
> > > > $ head -1 testscript
> > > > #!/bin/sh
> > > > $ ./testscript bash: ./testscript: No such file or directory
> > > What kernel wants
Jeff Mcadams wrote:
> Also sprach Rik van Riel
> >On Mon, 5 Mar 2001, John Kodis wrote:
> >> On Mon, Mar 05, 2001 at 08:40:22AM -0500, Richard B. Johnson wrote:
> >> > Somebody must have missed the boat entirely. Unix does not, never
> >> > has, and never will end a text line with '\r'.
>
> >>
Also sprach Rik van Riel
>On Mon, 5 Mar 2001, John Kodis wrote:
>> On Mon, Mar 05, 2001 at 08:40:22AM -0500, Richard B. Johnson wrote:
>> > Somebody must have missed the boat entirely. Unix does not, never
>> > has, and never will end a text line with '\r'.
>> Unix does not, never has, and never
On 5 Mar 2001, Jan Nieuwenhuizen wrote:
> "Richard B. Johnson" <[EMAIL PROTECTED]> writes:
>
> > So why would you even consider breaking bash as a work-around for
> > a broken script?
>
> I don't.
>
> > Somebody must have missed the boat entirely. Unix does not, never
> > has, and never will
On Mon, 5 Mar 2001, John Kodis wrote:
> On Mon, Mar 05, 2001 at 08:40:22AM -0500, Richard B. Johnson wrote:
>
> > Somebody must have missed the boat entirely. Unix does not, never
> > has, and never will end a text line with '\r'.
>
> Unix does not, never has, and never will end a text line
On Mon, 5 Mar 2001, John Kodis wrote:
> On Mon, Mar 05, 2001 at 08:40:22AM -0500, Richard B. Johnson wrote:
>
> > Somebody must have missed the boat entirely. Unix does not, never
> > has, and never will end a text line with '\r'.
>
> Unix does not, never has, and never will end a text line
On Mon, Mar 05, 2001 at 08:40:22AM -0500, Richard B. Johnson wrote:
> Somebody must have missed the boat entirely. Unix does not, never
> has, and never will end a text line with '\r'.
Unix does not, never has, and never will end a text line with ' ' (a
space character) or with \t (a tab
Jan Nieuwenhuizen <[EMAIL PROTECTED]> writes:
|> Pavel Machek <[EMAIL PROTECTED]> writes:
|>
|> > > $ head -1 testscript
|> > > #!/bin/sh
|> > > $ ./testscript
|> > > bash: ./testscript: No such file or directory
^
|> >
|> > What kernel wants
On 5 Mar 2001, Jan Nieuwenhuizen wrote:
> Pavel Machek <[EMAIL PROTECTED]> writes:
>
> > > $ head -1 testscript
> > > #!/bin/sh
> > > $ ./testscript
> > > bash: ./testscript: No such file or directory
> >
> > What kernel wants to say is "/usr/bin/perl\r: no such file". Saying ENOEXEC
> > would
Pavel Machek <[EMAIL PROTECTED]> writes:
> > $ head -1 testscript
> > #!/bin/sh
> > $ ./testscript
> > bash: ./testscript: No such file or directory
>
> What kernel wants to say is "/usr/bin/perl\r: no such file". Saying ENOEXEC
> would be even more confusing.
So, why don't we make bash say
Pavel Machek [EMAIL PROTECTED] writes:
$ head -1 testscript
#!/bin/sh
$ ./testscript
bash: ./testscript: No such file or directory
What kernel wants to say is "/usr/bin/perl\r: no such file". Saying ENOEXEC
would be even more confusing.
So, why don't we make bash say that, then? As
Jan Nieuwenhuizen [EMAIL PROTECTED] writes:
| Pavel Machek [EMAIL PROTECTED] writes:
|
| $ head -1 testscript
| #!/bin/sh
| $ ./testscript
| bash: ./testscript: No such file or directory
^
|
| What kernel wants to say is
On 5 Mar 2001, Jan Nieuwenhuizen wrote:
Pavel Machek [EMAIL PROTECTED] writes:
$ head -1 testscript
#!/bin/sh
$ ./testscript
bash: ./testscript: No such file or directory
What kernel wants to say is "/usr/bin/perl\r: no such file". Saying ENOEXEC
would be even more
On Mon, Mar 05, 2001 at 08:40:22AM -0500, Richard B. Johnson wrote:
Somebody must have missed the boat entirely. Unix does not, never
has, and never will end a text line with '\r'.
Unix does not, never has, and never will end a text line with ' ' (a
space character) or with \t (a tab
On Mon, 5 Mar 2001, John Kodis wrote:
On Mon, Mar 05, 2001 at 08:40:22AM -0500, Richard B. Johnson wrote:
Somebody must have missed the boat entirely. Unix does not, never
has, and never will end a text line with '\r'.
Unix does not, never has, and never will end a text line with ' ' (a
On Mon, 5 Mar 2001, John Kodis wrote:
On Mon, Mar 05, 2001 at 08:40:22AM -0500, Richard B. Johnson wrote:
Somebody must have missed the boat entirely. Unix does not, never
has, and never will end a text line with '\r'.
Unix does not, never has, and never will end a text line with ' '
On 5 Mar 2001, Jan Nieuwenhuizen wrote:
"Richard B. Johnson" [EMAIL PROTECTED] writes:
So why would you even consider breaking bash as a work-around for
a broken script?
I don't.
Somebody must have missed the boat entirely. Unix does not, never
has, and never will end a text line
Also sprach Rik van Riel
On Mon, 5 Mar 2001, John Kodis wrote:
On Mon, Mar 05, 2001 at 08:40:22AM -0500, Richard B. Johnson wrote:
Somebody must have missed the boat entirely. Unix does not, never
has, and never will end a text line with '\r'.
Unix does not, never has, and never will end a
Jeff Mcadams wrote:
Also sprach Rik van Riel
On Mon, 5 Mar 2001, John Kodis wrote:
On Mon, Mar 05, 2001 at 08:40:22AM -0500, Richard B. Johnson wrote:
Somebody must have missed the boat entirely. Unix does not, never
has, and never will end a text line with '\r'.
Unix does not,
On Mon, Mar 05, 2001 at 08:40:22AM -0500, Richard B. Johnson wrote:
On 5 Mar 2001, Jan Nieuwenhuizen wrote:
Pavel Machek [EMAIL PROTECTED] writes:
$ head -1 testscript
#!/bin/sh
$ ./testscript bash: ./testscript: No such file or directory
What kernel wants to say is
Followup to: [EMAIL PROTECTED]
By author:"Richard B. Johnson" [EMAIL PROTECTED]
In newsgroup: linux.dev.kernel
The '\r' (^R) definitely has special significance to Unix. It's called
"VREPRINT", in the termios structure member "c_cc".
'\r' is ^M, not ^R.
There is really no such thing
On Mon, 5 Mar 2001, Paul Flinders wrote:
Jeff Mcadams wrote:
Also sprach Rik van Riel
On Mon, 5 Mar 2001, John Kodis wrote:
On Mon, Mar 05, 2001 at 08:40:22AM -0500, Richard B. Johnson wrote:
Somebody must have missed the boat entirely. Unix does not, never
has, and never will
Andreas Schwab wrote:
This [isspace('\r') == 1] has no significance here. The right thing to
look at is $IFS, which does not contain \r by default. The shell only splits
words by "IFS whitespace", and the kernel should be consistent with it:
$ echo -e 'ls foo\r' | sh
ls: foo: No such
Paul Flinders wrote:
uses space (0x20) and tab (0x8) as white space and no other character.
sigh I mean, of course, tab (_0x9_)
I just checked - the kernel isspace() macro says that \r is whitespace.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
"Richard B. Johnson" [EMAIL PROTECTED] writes:
No. I did not miss the point. The 'No such file or directory' error
(when you can see the ^$^$)#@@* filename with 'ls'), usually means
that there is something wrong with the file.
Now, let's see. When this error happens, it can be one of these:
On Mon, Mar 05, 2001 at 07:58:52PM +0100, Pozsar Balazs wrote:
And what does POSIX say about "#!/bin/sh\r" ?
In other words: should the kernel look for the interpreter between the !
and the newline, or [the first space or newline] or the first whitespace?
IMHO, the first whitespace. Which
On Mon, 5 Mar 2001, Robert Read wrote:
On Mon, Mar 05, 2001 at 07:58:52PM +0100, Pozsar Balazs wrote:
And what does POSIX say about "#!/bin/sh\r" ?
In other words: should the kernel look for the interpreter between the !
and the newline, or [the first space or newline] or the first
And what does POSIX say about "#!/bin/sh\r" ?
Nothing at all. The #! construction is not part of any standard
right now. The implementation is messy - different operating systems
do vaguely similar things, but all details differ.
Linux can do whatever it wants.
Of course it helps portability if
On Mon, 5 Mar 2001, John Kodis wrote:
On Mon, Mar 05, 2001 at 08:40:22AM -0500, Richard B. Johnson wrote:
Somebody must have missed the boat entirely. Unix does not, never
has, and never will end a text line with '\r'.
Unix does not, never has, and never will end a text line with ' '
On Mon, Mar 05, 2001 at 10:05:36PM +0100, Pozsar Balazs wrote:
On Mon, 5 Mar 2001, Robert Read wrote:
On Mon, Mar 05, 2001 at 07:58:52PM +0100, Pozsar Balazs wrote:
And what does POSIX say about "#!/bin/sh\r" ?
In other words: should the kernel look for the interpreter between the !
Hi!
> > > When running a script (perl in this case) that has DOS-style
> > > newlines (\r\n), Linux 2.4.2 can't find an interpreter because it
> > > doesn't recognize the \r. The following patch should fix this
> > > (untested).
>
> > Fix the script. The kernel expects a specific format
>
>
Hi!
When running a script (perl in this case) that has DOS-style
newlines (\r\n), Linux 2.4.2 can't find an interpreter because it
doesn't recognize the \r. The following patch should fix this
(untested).
Fix the script. The kernel expects a specific format
How about
Followup to: <[EMAIL PROTECTED]>
By author:Jamie Lokier <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
>
> David wrote:
> > We wouldn't make the kernel translate m$ word docs into files the kernel
> > can parse. It's a userland thing and changing the kernel would change a
> > legacy
On Tue, Feb 27, 2001 at 01:44:08PM +, Alan Cox wrote:
> > When running a script (perl in this case) that has DOS-style
> > newlines (\r\n), Linux 2.4.2 can't find an interpreter because it
> > doesn't recognize the \r. The following patch should fix this
> > (untested).
> Fix the script.
David wrote:
> We wouldn't make the kernel translate m$ word docs into files the kernel
> can parse. It's a userland thing and changing the kernel would change a
> legacy that would cause a lot of confusion I would expect.
Now there's a thought. binfmt_fileextension, chooses the interpreter
David wrote:
We wouldn't make the kernel translate m$ word docs into files the kernel
can parse. It's a userland thing and changing the kernel would change a
legacy that would cause a lot of confusion I would expect.
Now there's a thought. binfmt_fileextension, chooses the interpreter
On Tue, Feb 27, 2001 at 01:44:08PM +, Alan Cox wrote:
When running a script (perl in this case) that has DOS-style
newlines (\r\n), Linux 2.4.2 can't find an interpreter because it
doesn't recognize the \r. The following patch should fix this
(untested).
Fix the script. The kernel
Followup to: [EMAIL PROTECTED]
By author:Jamie Lokier [EMAIL PROTECTED]
In newsgroup: linux.dev.kernel
David wrote:
We wouldn't make the kernel translate m$ word docs into files the kernel
can parse. It's a userland thing and changing the kernel would change a
legacy that would
Alistair Riddell wrote:
> On Tue, 27 Feb 2001, Heusden, Folkert van wrote:
>
>> But; it's not that much of hassle to run it trough some awk/sed/whatsoever
>> script, would it? Imho there should be as less as possible code in the
>
>
> man fromdos (on most linux systems anyway)
>
tr -d '\r'
Tim Waugh wrote:
> > Isn't `perl' overkill? Why not just:
> >
> > tr -d '\r'
>
> while read line; do echo ${line%?}; done
And those can be convert a set of files as "fromdos *.c" can they?
:-)
-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body
On Tue, Feb 27, 2001 at 12:59:48PM -0700, Don Dugger wrote:
> Isn't `perl' overkill? Why not just:
>
> tr -d '\r'
while read line; do echo ${line%?}; done
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More
1 - 100 of 128 matches
Mail list logo
