Question about system generation
Hello, I want to do a new "distro" (home-brew) in some weeks, when kernel 2.4 runs fine with gcc-3.0 when it's finished. I want to use libc5 because I prefer it over GNU and it's smaller. Is it possible or do I have to expect major problems? I know that I won't be able to use IPv6 etc. but that's not important. Last distro I had good experience with 2.0.38 and libc5.4.46. And, are there ANY updates to 5.4.46 (security and/or bugfix?) TIA - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Question about system generation
Hello, I want to do a new "distro" (home-brew) in some weeks, when kernel 2.4 runs fine with gcc-3.0 when it's finished. I want to use libc5 because I prefer it over GNU and it's smaller. Is it possible or do I have to expect major problems? I know that I won't be able to use IPv6 etc. but that's not important. Last distro I had good experience with 2.0.38 and libc5.4.46. And, are there ANY updates to 5.4.46 (security and/or bugfix?) TIA - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: generic rwsem
Thanks a lot, andrea, this patch (I only applied the rwsem one) finally fixes the rwsem compile problem with gcc-3.0-20010417. Now I can get a working kernel ;-) -mirabilos - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: generic rwsem
Thanks a lot, andrea, this patch (I only applied the rwsem one) finally fixes the rwsem compile problem with gcc-3.0-20010417. Now I can get a working kernel ;-) -mirabilos - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Still cannot compile, 2.4.3-ac6
Dear Sirs, I still cannot compile with gcc-3.0 from 08.04. Yesterday I tried -ac5 (same problem reported earlier) and using egcs-2.91.66 for _only_ the peoblematic files (sys.c exec.c binfmt_elf.c and two others which I dont remember) but the kernel could not boot. Now I get: gcc -D__KERNEL__ -I/glc/build/linux/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 -march=i686-DEXPORT_SYMTAB -c signal.c gcc -D__KERNEL__ -I/glc/build/linux/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 -march=i686-DEXPORT_SYMTAB -c sys.c sys.c: In function `sys_gethostname': /glc/build/linux/include/asm/rwsem-xadd.h:153: inconsistent operand constraints in an `asm' make[2]: *** [sys.o] Error 1 make[2]: Leaving directory `/glc/build/linux/kernel' make[1]: *** [first_rule] Error 2 make[1]: Leaving directory `/glc/build/linux/kernel' make: *** [_dir_kernel] Error 2 ecce:/usr/src/linux # And ver_linux reports: ecce:/usr/src/linux # sh scripts/ver_linux If some fields are empty or look unusual you may have an old version. Compare to the current minimal requirements in Documentation/Changes. Linux ecce.homeip.net 2.4.3-ac3 #3 Sun Apr 8 22:06:09 /etc/localtime 2001 i686 unknown Gnu C 3.0 Gnu make 3.77 binutils 2.10.0.33 util-linux 2.11a mount 2.11a modutils 2.4.5 e2fsprogs 1.19 reiserfsprogs 3.x.0j PPP2.4.1b2 Linux C Libraryx 1 root root 1248080 Apr 8 21:14 /lib/libc.so.6 Dynamic linker (ldd) 2.2 Procps 1.2.11 Net-tools 1.59 Kbd0.99 Sh-utils 1.16 Modules Loaded ecce:/usr/src/linux # LIBC6 is originally from SuSE 6.2 but I updated with the one from SuSE 7.1 manually (I think I have both here?? will recompile soon glibc-2.2.2) If any of you could help me, thanks in advance. The problem _did_ _not_ exist with same gcc-3 and 2.4.3-ac3. It doesn't vanish when I get the full patches, not the interdiffs. -mirabilos - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Still cannot compile, 2.4.3-ac6
Dear Sirs, I still cannot compile with gcc-3.0 from 08.04. Yesterday I tried -ac5 (same problem reported earlier) and using egcs-2.91.66 for _only_ the peoblematic files (sys.c exec.c binfmt_elf.c and two others which I dont remember) but the kernel could not boot. Now I get: gcc -D__KERNEL__ -I/glc/build/linux/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 -march=i686-DEXPORT_SYMTAB -c signal.c gcc -D__KERNEL__ -I/glc/build/linux/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 -march=i686-DEXPORT_SYMTAB -c sys.c sys.c: In function `sys_gethostname': /glc/build/linux/include/asm/rwsem-xadd.h:153: inconsistent operand constraints in an `asm' make[2]: *** [sys.o] Error 1 make[2]: Leaving directory `/glc/build/linux/kernel' make[1]: *** [first_rule] Error 2 make[1]: Leaving directory `/glc/build/linux/kernel' make: *** [_dir_kernel] Error 2 ecce:/usr/src/linux # And ver_linux reports: ecce:/usr/src/linux # sh scripts/ver_linux If some fields are empty or look unusual you may have an old version. Compare to the current minimal requirements in Documentation/Changes. Linux ecce.homeip.net 2.4.3-ac3 #3 Sun Apr 8 22:06:09 /etc/localtime 2001 i686 unknown Gnu C 3.0 Gnu make 3.77 binutils 2.10.0.33 util-linux 2.11a mount 2.11a modutils 2.4.5 e2fsprogs 1.19 reiserfsprogs 3.x.0j PPP2.4.1b2 Linux C Libraryx 1 root root 1248080 Apr 8 21:14 /lib/libc.so.6 Dynamic linker (ldd) 2.2 Procps 1.2.11 Net-tools 1.59 Kbd0.99 Sh-utils 1.16 Modules Loaded ecce:/usr/src/linux # LIBC6 is originally from SuSE 6.2 but I updated with the one from SuSE 7.1 manually (I think I have both here?? will recompile soon glibc-2.2.2) If any of you could help me, thanks in advance. The problem _did_ _not_ exist with same gcc-3 and 2.4.3-ac3. It doesn't vanish when I get the full patches, not the interdiffs. -mirabilos - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Basic Text Mode (was: Re: Question about SysRq)
> Thought, i really love all sysrq properties of linux, so i need less often > to make hardware resets an then await and fear, what fsck will print. 101% ACK > One more property, that i'd like to have should be request key to force the > most basic text mode (say 80x25) on the console, when eg. X freezes and > i kill its session, then last gfx mode resides on the screen and see no way > to restore back the text mode - /usr/bin/reset or something alike will not > do it. But it seems to be not a good idea at all, does it ? It is a very good idea, and to implement quite easy. You just do have to diff between three types of video cards (MDA, MGA and HGC vs. CGA and AGA vs. EGA+). Then you do direct register writes. For the HGC I did it recently in a DOS proggy which switched from text to gfx and back. I had a TSR which simulated a gfx BIOS. Only problem is, I lost the source. But I could rewrite and test it on request. I even would put it under GPL for the kernel (normally this is a no-no for me), just ask me. I will write it in NASM then because I can't the AT syntax. For non-i386 Platforms I do not know about this topic. (IIRC the Apples didnt even have a text mode) Maybe I could look up the EGA register values somewhere. -mirabilos - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Basic Text Mode (was: Re: Question about SysRq)
Thought, i really love all sysrq properties of linux, so i need less often to make hardware resets an then await and fear, what fsck will print. 101% ACK One more property, that i'd like to have should be request key to force the most basic text mode (say 80x25) on the console, when eg. X freezes and i kill its session, then last gfx mode resides on the screen and see no way to restore back the text mode - /usr/bin/reset or something alike will not do it. But it seems to be not a good idea at all, does it ? It is a very good idea, and to implement quite easy. You just do have to diff between three types of video cards (MDA, MGA and HGC vs. CGA and AGA vs. EGA+). Then you do direct register writes. For the HGC I did it recently in a DOS proggy which switched from text to gfx and back. I had a TSR which simulated a gfx BIOS. Only problem is, I lost the source. But I could rewrite and test it on request. I even would put it under GPL for the kernel (normally this is a no-no for me), just ask me. I will write it in NASM then because I can't the ATT syntax. For non-i386 Platforms I do not know about this topic. (IIRC the Apples didnt even have a text mode) Maybe I could look up the EGA register values somewhere. -mirabilos - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: binfmt_script and ^M
- 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 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: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 all programs for \r\n.
> >
> > That is no sarcasm, it is ridiculous. CRLF line endings are ISO-IR-6 and
> > US-ASCII standard, and even UN*X systems used them when they had printers
> > (typewriters?) as output device, and no screens. With the Virtual Terminal,
> > Virtual Console stuff times may have changed but we have so many old stuff
> > in it... I won't remove them or didn't think of, but I remember you of:
> > - lost+found
> > - using ESC (or Alt???) as META for _shell commands_ which
> >easily could be Ctrl-Left, Ctrl-Right, Ctrl-Del etc.
> > - EMACS:-((
> > - ED/EX/VI :-(
> >
>
> This is pure bullshit, so I'm not copying my response to the list. None of that
> depends on the kernel.
I did not ever say that it depends on the kernel. The kernel _has to_ depend on
_standards_ coz otherwise it wouldn't be POSIX compliant, it wouldn't obey one
of the most basic ISO standards nowadays, etc. etc.
The kernel is faulty, and it has to use as CARRIAGE RETURN, whenever this
behaviour seems expactable (stress on -able).
> If he's to lame to do:
>
> for i in `find . -type f | grep -l "#! .*perl\r"`; do
> perl -pie 's|\r||g' < $i
> done
>
> ...or...
>
> ln -snf `which perl`{,\r}
>
> ...or...
>
> change his scripts to use "perl -w", which works, and he should use anyway
>
> ...or...
>
> Run his scripts directly by doing "perl /the/path/to/broken/script" (which also
> works)
>
> ...or any of the other solutions that various people suggested
_I_ am not talking about perl coz in my eyes this is waste. But there are numerous
other programmes with problems on it, too.
> ...then why should we accept a kernel patch to fix this non-problem? This is
> just plain ludicrous.
>
>
> Sean
>
> >
> > The following does _not_ have to do with any US-ASCII or ISO_646.irv:1991
> > standards which IIRC are inherited by POSIX.
> > > And why not make all program use filenames that have an 8+3 char garbled
> > > equivalent where the last 3 are the indicators of the filetype. Oh, and
> > > let's do everything to make sure the user doesn't leave Gnome/KDE.
> > > And of course, let's add new features to all existing protocols and
> > > other standards to make them "superior" to other implementations.
> > > Oh, and of course, we must require an extra 64 MB of memory and
> > > 500 MB of diskspace for each release, and a 200MHz faster processor.
> > > And let us do all system settings through a registry.
> > >
> > > OH! Let's change the name of the operating-system to something more
> > > catchy. Hmmm. Let's see. Windows maybe...
> > >
> > >
> > >
> > > /David
> >
> > I _do_ _not_ like Windoze either, but we live in a world
> > where we have to cope with it. I am even to code windoze
> > apps in order to support linux (no comment on this)...
> >
-mirabilos
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: binfmt_script and ^M
- 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 -0000, Thorsten Glaser Geuer wrote:
- 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: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 all programs for \r\n.
That is no sarcasm, it is ridiculous. CRLF line endings are ISO-IR-6 and
US-ASCII standard, and even UN*X systems used them when they had printers
(typewriters?) as output device, and no screens. With the Virtual Terminal,
Virtual Console stuff times may have changed but we have so many old stuff
in it... I won't remove them or didn't think of, but I remember you of:
- lost+found
- using ESC (or Alt???) as META for _shell commands_ which
easily could be Ctrl-Left, Ctrl-Right, Ctrl-Del etc.
- EMACS:-((
- ED/EX/VI :-(
This is pure bullshit, so I'm not copying my response to the list. None of that
depends on the kernel.
I did not ever say that it depends on the kernel. The kernel _has to_ depend on
_standards_ coz otherwise it wouldn't be POSIX compliant, it wouldn't obey one
of the most basic ISO standards nowadays, etc. etc.
The kernel is faulty, and it has to use h0D as CARRIAGE RETURN, whenever this
behaviour seems expactable (stress on -able).
If he's to lame to do:
for i in `find . -type f | grep -l "#! .*perl\r"`; do
perl -pie 's|\r||g' $i
done
...or...
ln -snf `which perl`{,\r}
...or...
change his scripts to use "perl -w", which works, and he should use anyway
...or...
Run his scripts directly by doing "perl /the/path/to/broken/script" (which also
works)
...or any of the other solutions that various people suggested
_I_ am not talking about perl coz in my eyes this is waste. But there are numerous
other programmes with problems on it, too.
...then why should we accept a kernel patch to fix this non-problem? This is
just plain ludicrous.
Sean
The following does _not_ have to do with any US-ASCII or ISO_646.irv:1991
standards which IIRC are inherited by POSIX.
And why not make all program use filenames that have an 8+3 char garbled
equivalent where the last 3 are the indicators of the filetype. Oh, and
let's do everything to make sure the user doesn't leave Gnome/KDE.
And of course, let's add new features to all existing protocols and
other standards to make them "superior" to other implementations.
Oh, and of course, we must require an extra 64 MB of memory and
500 MB of diskspace for each release, and a 200MHz faster processor.
And let us do all system settings through a registry.
OH! Let's change the name of the operating-system to something more
catchy. Hmmm. Let's see. Windows maybe...
/sarcasm
/David
I _do_ _not_ like Windoze either, but we live in a world
where we have to cope with it. I am even to code windoze
apps in order to support linux (no comment on this)...
-mirabilos
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: binfmt_script and ^M
- 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: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 all programs for \r\n. That is no sarcasm, it is ridiculous. CRLF line endings are ISO-IR-6 and US-ASCII standard, and even UN*X systems used them when they had printers (typewriters?) as output device, and no screens. With the Virtual Terminal, Virtual Console stuff times may have changed but we have so many old stuff in it... I won't remove them or didn't think of, but I remember you of: - lost+found - using ESC (or Alt???) as META for _shell commands_ which easily could be Ctrl-Left, Ctrl-Right, Ctrl-Del etc. - EMACS:-(( - ED/EX/VI :-( The following does _not_ have to do with any US-ASCII or ISO_646.irv:1991 standards which IIRC are inherited by POSIX. > And why not make all program use filenames that have an 8+3 char garbled > equivalent where the last 3 are the indicators of the filetype. Oh, and > let's do everything to make sure the user doesn't leave Gnome/KDE. > And of course, let's add new features to all existing protocols and > other standards to make them "superior" to other implementations. > Oh, and of course, we must require an extra 64 MB of memory and > 500 MB of diskspace for each release, and a 200MHz faster processor. > And let us do all system settings through a registry. > > OH! Let's change the name of the operating-system to something more > catchy. Hmmm. Let's see. Windows maybe... > > > > /David I _do_ _not_ like Windoze either, but we live in a world where we have to cope with it. I am even to code windoze apps in order to support linux (no comment on this)... -mirabilos - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: binfmt_script and ^M
- 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 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 character). Yet if I begin a shell > > script with '#!/bin/sh ' or '#!/bin/sh\t', the training white space is > > striped and /bin/sh gets exec'd. Since \r has no special significance > > to Unix, I'd expect it to be treated the same as any other whitespace > > character -- it should be striped, and /bin/sh should get exec'd. > > Actually it does have some significance - it causes a return, then the > following text overwrites the current text. Granted, this is only used > occasionally for generating bold/underline/... > > This is used in some formatters (troff) occasionally, though it tends to > use backspace now. Less supports it, but ^H is quite more oftenly used. ISO_646.irv:1991 aka ISO-IR-6 aka US-ASCII-7 _also_ defines it, and we're going to be not ASCII-compatible any longer if we aren't going to support CRLF line endings. I also oftenly have the other problem round: LF endings in files which are to be viewed under DOS. I use a 15-year-old text editor from Digital Research (yes, DOS 3.41) which still is fine under W** and DOSEMU, it looks like jstar only that I miss find and replace. IMHO those problems could be solved with programmes/kernels/libs accepting LF as line ending and CRLF (and possibly CRCRLF ...) as a synonyme for LF, but treat CR non-LF differently. I have seen this behaviour quite often in the past and am using it for myself, too (except for native assembly progs). > \r is not considered whitespace, though it should be possible to define > it that way. A line terminator is always \n. ACK > Another point, is that the "#!/bin/sh" can have options added: it can be > "#!/bin/sh -vx" and the option -vx is passed to the shell. The space is > not just "stripped". It is used as a parameter separator. As such, the > "stripping" is only because the first parameter is separated from the > command by whitespace. That's why I suggest treating CRLF (and only CR only-LF) as LF. -mirabilos - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: binfmt_script and ^M
- 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 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 character). Yet if I begin a shell script with '#!/bin/sh ' or '#!/bin/sh\t', the training white space is striped and /bin/sh gets exec'd. Since \r has no special significance to Unix, I'd expect it to be treated the same as any other whitespace character -- it should be striped, and /bin/sh should get exec'd. Actually it does have some significance - it causes a return, then the following text overwrites the current text. Granted, this is only used occasionally for generating bold/underline/... This is used in some formatters (troff) occasionally, though it tends to use backspace now. Less supports it, but ^H is quite more oftenly used. ISO_646.irv:1991 aka ISO-IR-6 aka US-ASCII-7 _also_ defines it, and we're going to be not ASCII-compatible any longer if we aren't going to support CRLF line endings. I also oftenly have the other problem round: LF endings in files which are to be viewed under DOS. I use a 15-year-old text editor from Digital Research (yes, DOS 3.41) which still is fine under W** and DOSEMU, it looks like jstar only that I miss find and replace. IMHO those problems could be solved with programmes/kernels/libs accepting LF as line ending and CRLF (and possibly CRCRLF ...) as a synonyme for LF, but treat CR non-LF differently. I have seen this behaviour quite often in the past and am using it for myself, too (except for native assembly progs). \r is not considered whitespace, though it should be possible to define it that way. A line terminator is always \n. ACK Another point, is that the "#!/bin/sh" can have options added: it can be "#!/bin/sh -vx" and the option -vx is passed to the shell. The space is not just "stripped". It is used as a parameter separator. As such, the "stripping" is only because the first parameter is separated from the command by whitespace. That's why I suggest treating CRLF (and only CR only-LF) as LF. -mirabilos - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: binfmt_script and ^M
- 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: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 all programs for \r\n. That is no sarcasm, it is ridiculous. CRLF line endings are ISO-IR-6 and US-ASCII standard, and even UN*X systems used them when they had printers (typewriters?) as output device, and no screens. With the Virtual Terminal, Virtual Console stuff times may have changed but we have so many old stuff in it... I won't remove them or didn't think of, but I remember you of: - lost+found - using ESC (or Alt???) as META for _shell commands_ which easily could be Ctrl-Left, Ctrl-Right, Ctrl-Del etc. - EMACS:-(( - ED/EX/VI :-( The following does _not_ have to do with any US-ASCII or ISO_646.irv:1991 standards which IIRC are inherited by POSIX. And why not make all program use filenames that have an 8+3 char garbled equivalent where the last 3 are the indicators of the filetype. Oh, and let's do everything to make sure the user doesn't leave Gnome/KDE. And of course, let's add new features to all existing protocols and other standards to make them "superior" to other implementations. Oh, and of course, we must require an extra 64 MB of memory and 500 MB of diskspace for each release, and a 200MHz faster processor. And let us do all system settings through a registry. OH! Let's change the name of the operating-system to something more catchy. Hmmm. Let's see. Windows maybe... /sarcasm /David I _do_ _not_ like Windoze either, but we live in a world where we have to cope with it. I am even to code windoze apps in order to support linux (no comment on this)... -mirabilos - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
test plz ignore
ping pong am I still on lkml? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
test plz ignore
ping pong am I still on lkml? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ISO-8859-1 completeness of kernel fonts?
- Original Message - From: "H. Peter Anvin" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, February 27, 2001 7:49 PM Subject: Re: ISO-8859-1 completeness of kernel fonts? > Followup to: <01c0a0ed$1ea188d0$[EMAIL PROTECTED]> > By author:"Thorsten Glaser Geuer" <[EMAIL PROTECTED]> > In newsgroup: linux.dev.kernel > > > > My second suggestion: code it as .psfu and load it by setfont, including > > the appropiate console-map. AFAIK all the kernel default fonts are cp437 > > (linux/drivers/char/cp437.uni; consolemap.*) > > > > Something that would be really good is if someone could contribute PSF > (v1 and v2) support for gfe <http://www.gnu.org/software/gfe/gfe.html> > or some other free font editor. > > -hpa I always do it by a BASIC programme under DOS (yep I know this isn't pure but I have a font editor from S-DOS aka PTS-DOS (the free version)). The SFE.COM allows me to design 8x8 8x12 8x14 8x16 fonts; the unicode table I write in the MC or VC (NC clone for DOS) editor; my BASIC pgm converts them together to PSFU. It's very easy once you read the psf docs. It's a pity that I've to mkfs the DOS partitions of my HDDs every handfull of weeks, otherwise I'd put them onto a ftp server somewhere. But I call you to try it by yourself. (perl prolly isn't that easy coz it goes to binary values, but GW-BASIC is fine) -mirabilos - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ISO-8859-1 completeness of kernel fonts?
> Hello, > > The 8x16 and Sun 12x22 kernel fonts I tried seem to lack some standard > glyphs necessary to represent the entire ISO-8859-1 charmap; I am talking > about all accented capital vowels except for 'I'. > > This seems to happen in both 2.2.16 as well as in 2.2.18. > > Is this intentional? If so, why? > > How can I override this behaviour? > > Thank you. > > Cheers, > > Mack Stevenson I have converted my fonts by hand (with a GW-BASIC proggy) from bitmap to .c, though not the SUN fonts for ISO but the PC fonts for cp437. I did this because I do not like e.g. the glyph "0" in standard font and included the "Euro" sign. (I use the same for DOS and Linux now, and even Windoze recently got it as Terminal font!) My second suggestion: code it as .psfu and load it by setfont, including the appropiate console-map. AFAIK all the kernel default fonts are cp437 (linux/drivers/char/cp437.uni; consolemap.*) -mirabilos - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ISO-8859-1 completeness of kernel fonts?
Hello, The 8x16 and Sun 12x22 kernel fonts I tried seem to lack some standard glyphs necessary to represent the entire ISO-8859-1 charmap; I am talking about all accented capital vowels except for 'I'. This seems to happen in both 2.2.16 as well as in 2.2.18. Is this intentional? If so, why? How can I override this behaviour? Thank you. Cheers, Mack Stevenson I have converted my fonts by hand (with a GW-BASIC proggy) from bitmap to .c, though not the SUN fonts for ISO but the PC fonts for cp437. I did this because I do not like e.g. the glyph "0" in standard font and included the "Euro" sign. (I use the same for DOS and Linux now, and even Windoze recently got it as Terminal font!) My second suggestion: code it as .psfu and load it by setfont, including the appropiate console-map. AFAIK all the kernel default fonts are cp437 (linux/drivers/char/cp437.uni; consolemap.*) -mirabilos - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ISO-8859-1 completeness of kernel fonts?
- Original Message - From: "H. Peter Anvin" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, February 27, 2001 7:49 PM Subject: Re: ISO-8859-1 completeness of kernel fonts? Followup to: 01c0a0ed$1ea188d0$[EMAIL PROTECTED] By author: "Thorsten Glaser Geuer" [EMAIL PROTECTED] In newsgroup: linux.dev.kernel My second suggestion: code it as .psfu and load it by setfont, including the appropiate console-map. AFAIK all the kernel default fonts are cp437 (linux/drivers/char/cp437.uni; consolemap.*) Something that would be really good is if someone could contribute PSF (v1 and v2) support for gfe http://www.gnu.org/software/gfe/gfe.html or some other free font editor. -hpa I always do it by a BASIC programme under DOS (yep I know this isn't pure but I have a font editor from S-DOS aka PTS-DOS (the free version)). The SFE.COM allows me to design 8x8 8x12 8x14 8x16 fonts; the unicode table I write in the MC or VC (NC clone for DOS) editor; my BASIC pgm converts them together to PSFU. It's very easy once you read the psf docs. It's a pity that I've to mkfs the DOS partitions of my HDDs every handfull of weeks, otherwise I'd put them onto a ftp server somewhere. But I call you to try it by yourself. (perl prolly isn't that easy coz it goes to binary values, but GW-BASIC is fine) -mirabilos - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OK to mount multiple FS in one dir?
- Original Message -
From: "Peter Samuelson" <[EMAIL PROTECTED]>
To: "Michael D. Crawford" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Tuesday, 6. February 2001 00:06
Subject: Re: OK to mount multiple FS in one dir?
>
> [Michael D. Crawford]
> > I found I could mount three partitions on /mnt
>
> Yes. New feature, appeared in the 2.4.0test series, or shortly before.
>
> > and they'd all show up as mounted at /mnt in the "mount" command, but
> > if I unmounted one of them (only tried with the currently visible
> > one), then it appeared that there were no filesystems mounted there,
> > but I could continue umounting until the other two were gone.
>
> util-linux gets rather confused by this feature. They say newer
> versions fix this.
>
> > But I had the 2.10r util-linux sources on my machine and installed
> > mount and umount from it, and I find that it gets it right mostly
> > when I mount and unmount multiple things, with the exception that if
> > /dev/sda5 was mounted before /dev/sda1, then if I give the command
> > "umount /dev/sda5", sda1 is the one that gets unmounted rather than
> > sda5, so it takes the most recently mounted filesystem rather than
> > the one you specify.
>
> I think this is a kernel limitation. 'umount' takes '/dev/sda5' and
> turns it into '/mnt/test' and calls umount("/mnt/test"). The kernel
> then unmounts whatever is on "top" of /mnt/test.
>
> I don't think there's anything umount can do about this behavior.
What about userland umount checking which device is umounted and
refusing to umount it or at least issuing a printf warning?
>
> Peter
-mirabilos
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: OK to mount multiple FS in one dir?
- Original Message -
From: "Peter Samuelson" [EMAIL PROTECTED]
To: "Michael D. Crawford" [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Tuesday, 6. February 2001 00:06
Subject: Re: OK to mount multiple FS in one dir?
[Michael D. Crawford]
I found I could mount three partitions on /mnt
Yes. New feature, appeared in the 2.4.0test series, or shortly before.
and they'd all show up as mounted at /mnt in the "mount" command, but
if I unmounted one of them (only tried with the currently visible
one), then it appeared that there were no filesystems mounted there,
but I could continue umounting until the other two were gone.
util-linux gets rather confused by this feature. They say newer
versions fix this.
But I had the 2.10r util-linux sources on my machine and installed
mount and umount from it, and I find that it gets it right mostly
when I mount and unmount multiple things, with the exception that if
/dev/sda5 was mounted before /dev/sda1, then if I give the command
"umount /dev/sda5", sda1 is the one that gets unmounted rather than
sda5, so it takes the most recently mounted filesystem rather than
the one you specify.
I think this is a kernel limitation. 'umount' takes '/dev/sda5' and
turns it into '/mnt/test' and calls umount("/mnt/test"). The kernel
then unmounts whatever is on "top" of /mnt/test.
I don't think there's anything umount can do about this behavior.
What about userland umount checking which device is umounted and
refusing to umount it or at least issuing a printf warning?
Peter
-mirabilos
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
