[comp.unix.wizards] Help! There's a slash '/' in my filename.

cowan@dover.sps.mot.com (Andrew H Cowan) (02/02/91)

I don't know how it happened... but I've got a directory (on a
Sun OS 4.0.3 machine) that contains two files with the slash '/'
character embedded in the filenames.  I recall a discussion about bogus
filenames in this group a while back, did anybody ever figure out how
to deal with filenames that contain slashes?

Now that I've got 'em, how can I get rid of them?

Its a tricky problem, because it seems that every command on the system 
tries to follow the name like it is a directory path.  Thus, every command 
returns "file or directory not found".  Wildcarding to uniquely identify 
the files is no help because the expanded filenames contain slashes. 

Help!!


                  \_/oo\_/ 
....................\||/..........................................
Andy Cowan...........||........cowan@soleil.sps.mot.com......AZ...
"Stop me, before I kill -9 again!"  -AC

n138ct@tamuts.tamu.edu (Brent Burton) (02/02/91)

Thesummary line sez it.  I had problems before with mysterious
control characters appearing in some file names as I typed them (due
to the noisy phone lines).  

  shouldn't something like:  rm "slash/file"
  work OK?  The shell takes whatever is in quotes on the input line
and passes it straight to the program's argv[n].  If the program
uses this string value to manipulate the file, then maybe the string
(and of course, the slash) are being passed to the FS manager of the
kernel.  Would the FS then use the '/' to find the file?
---
Or another idea:
   use     'rm -i *'  -- rm asks you before each file whether or not to
delete it.  DON'T HOLD ME RESPONSIBLE FOR THIS.  CHECK YOUR LOCAL MAN
PAGES BEFORE DOING THIS!

---- I hope one of these ideas work...

             +----------------------+--------------------------+
             | Brent P. Burton      | n138ct@tamuts.tamu.edu   |
             | Texas A&M University | Computer Science/Physics |
             +----------------------+--------------------------+

D.Nash@utexas.edu (Donald L. Nash) (02/02/91)

In article <11714@helios.TAMU.EDU> you write:
>  shouldn't something like:  rm "slash/file"
>  work OK?

This won't work.  The / is not interpreted by the shell, but by the
kernel routine namei(), which translates file names into inode numbers. 
The interpretation of the / character is wired into namei()'s brain. 
Any solution which involves using the unlink() system call to remove the
file will fail because namei() will gag on that /.  I've never had to
deal with this problem before, but I seem to remember hearing a
solution.  Please wizards, don't flame me if I'm wrong, I'm only a
wizard in training.  Just politely point out my mistake and we'll all be
happy.  Anyway, if you "ls -i" in the directory containing this bogon
file, you'll get the inode number for it.  You can then use the clri
command to zap this inode.  This will leave all the links which pointed
to this inode hanging loose, including the bogon link.  It will also
leave all the blocks associated with the file "missing," i.e. they won't
be on the free list and the won't be allocated to files.  After you run
clri, unmount the filesystem and run fsck on it to repair the damage. 
This should get rid of all the hanging links and place the lost blocks
on the free list.  BTW, you'd better do this in single-user mode so no
one will have open files on the filesystem when you try to dismount it,
otherwise you won't be able to dismount it.  Be sure to read the man
pages for clri and fsck before you do any of this.

				Donald L. Nash

				The University of Texas System
				Office of Telecommunication Services

Internet:  D.Nash@utexas.edu
THEnet:    THENIC::DON
BITNET:    DON@THENIC
PSI Mail:  311051200131::DON

jmason@gpu.utcs.utoronto.ca (Jamie Mason) (02/02/91)

In article <43579@ut-emx.uucp> D.Nash@utexas.edu writes:
>The interpretation of the / character is wired into namei()'s brain. 

>be on the free list and the won't be allocated to files.  After you run
>clri, unmount the filesystem and run fsck on it to repair the damage. 

Why go to all that trouble to deal with the file.  Just rename it.  That
is to say, edit the directory and change the / to something harmless like
a '_' or a '.' or antything else.

I don't remember how hard it is to get around the restriction to writing
directories as if they were files, but that would seem easier than
clearing the inode and then picking up the peices of the file system.  Of
course if writing to the directory was becoming a problem, you could
always get the directory's sector number from it's Inode and pull out a
sector editor on the appropriate block /device. :-)

Jamie  ...  "Who was that Masked Interrupt?"
Written On  Saturday, February 2, 1991  at  06:31:32am EST

bs@marvin.e17.physik.tu-muenchen.de (Bernhard Schneck) (02/03/91)

>I don't remember how hard it is to get around the restriction to writing
>directories as if they were files, but that would seem easier than
>clearing the inode and then picking up the peices of the file system.  Of
>course if writing to the directory was becoming a problem, you could
>always get the directory's sector number from it's Inode and pull out a
>sector editor on the appropriate block /device. :-)

Not even that hard ... unmount the filesystem, and run fsdb (the file
system debugger) on it.  My SysV.3.2 box had one for ths S51K, and the
4.3-tahoe and 4.3-reno releases have it for FFS (4.2) filesystems (in
/etc and /sbin resp.)

>Jamie  ...  "Who was that Masked Interrupt?"

\Bernhard.
--

Bernhard Schneck        Internet: B.Schneck@Marvin.E17.Physik.TU-Muenchen.DE
TU Muenchen Physik E17            Postmaster@Physik.TU-Muenchen.DE
8046 Garching           BitNET  : schneck@dgablg5p
West Germany            

mike (Michael Stefanik) (02/03/91)

In an article, tamuts.tamu.edu!n138ct (Brent Burton) writes:
>shouldn't something like:  rm "slash/file"
>work OK? [ ... ]

No, this won't work.  The kernel does the translation of pathname to inode,
and the slash is considered a inviolate holy relic.  The shell has nothing
to do with this translation, so escaping, quoting, etc. won't accomplish
anything.  A slash in a filename means a corrupted filesytem, and fsck
should be run (my flavor of fsck will complain about "illegal pathname chars"
and will replace them with hash-marks).

-- 
Michael Stefanik                       | Opinions stated are not even my own.
Systems Engineer, Briareus Corporation | UUCP: ...!uunet!bria!mike
-------------------------------------------------------------------------------
technoignorami (tek'no-ig'no-ram`i) a group of individuals that are constantly
found to be saying things like "Well, it works on my DOS machine ..."

donlash@uncle.uucp (Donald Lashomb) (02/03/91)

In article <11714@helios.TAMU.EDU> n138ct@tamuts.tamu.edu (Brent Burton) writes:
=
=Thesummary line sez it.  I had problems before with mysterious
=control characters appearing in some file names as I typed them (due
=to the noisy phone lines).  
=
=  shouldn't something like:  rm "slash/file"
=  work OK?  The shell takes whatever is in quotes on the input line
=and passes it straight to the program's argv[n].  If the program
=uses this string value to manipulate the file, then maybe the string
=(and of course, the slash) are being passed to the FS manager of the
=kernel.  Would the FS then use the '/' to find the file?
=---
=Or another idea:
=   use     'rm -i *'  -- rm asks you before each file whether or not to
=delete it.  DON'T HOLD ME RESPONSIBLE FOR THIS.  CHECK YOUR LOCAL MAN
=PAGES BEFORE DOING THIS!
=
=---- I hope one of these ideas work...

I'm not a wizard, so anything I tell you here is only my best guess:

It's my understanding that the kernel itself disallows '/' in a filename,
so there's no way to get normal commands to accept it.  Try using ls -i
to get the inode # for the file, then (in single-user mode, or with the
filesystem umount'ed, or at least on a quiet system) use clri to remove
the inode followed by fsck to recover the (now unattached) data blocks.
Read your manuals carefully before trying this.

Don

marc@arnor.uucp (02/05/91)

An alternative is to make a new directory with the same parent as the
bad one.  Then HARD link all the other files into the new directory.
Then blow away the bad one.  You will probably have to unlink the bad
directory to blow it away.  Having done that, you should fsck the file
system to clean up.
--


Marc Auslander       <marc@ibm.com>

jackal@munsell.UUCP (Phil Hammar) (02/05/91)

	This used to happen here quite often, usually because someone
with a MAC would use GatorShare to write a file via NFS whose name
included the date.  The easiest solution was to use the MAC to change
the name to something without the '/'.  Then I would carefully explain
to the user what they did wrong and why they would be publicly flogged
if they did it again (restore really gets goofy if it is reading a
file system which contain such names).

			Phil

[

	
-- 
			Philip Hammar
	Sys. Admin. for AES of EPPS,a wholly owned subsidiary of E. KODAK Co.
UUCP: ...!{harvard!ima,uunet!atexnet}!munsell!jackal 	Phone: (617)276-7249
Internet: jackal@epps.kodak.com

greywolf@unisoft.UUCP (The Grey Wolf) (02/05/91)

In article <1991Feb2.113410.23943@gpu.utcs.utoronto.ca> jmason@gpu.utcs.utoronto.ca (Jamie Mason) writes:
>In article <43579@ut-emx.uucp> D.Nash@utexas.edu writes:
>>The interpretation of the / character is wired into namei()'s brain. 
>
>>be on the free list and the won't be allocated to files.  After you run
>>clri, unmount the filesystem and run fsck on it to repair the damage. 
>
>Why go to all that trouble to deal with the file.  Just rename it.  That
>is to say, edit the directory and change the / to something harmless like
>a '_' or a '.' or antything else.

Can't.  The kernel's namei() routine will choke on the '/' and try to make
an absolute path out of it.

>
>I don't remember how hard it is to get around the restriction to writing
>directories as if they were files, but that would seem easier than
>clearing the inode and then picking up the peices of the file system.

Not at all:

go single-user (this scenario constitutes enough concern to warrant this)
ls -i <dir-of-offending-file>
cd /
umount <fs-upon-which-offending-file-resides>
clri filesystem ino

If you have to do this on root, a "reboot -q -n" is necessary.

>Of
>course if writing to the directory was becoming a problem, you could
>always get the directory's sector number from it's Inode and pull out a
>sector editor on the appropriate block /device. :-)

Why go to all the trouble to map the file like that when clri(8) does just
what the user needs to do?  If the user has data in there, he's screwed
if he needs to access it (unless he can hack the filesystem to find the
inode).

It's a good thing that corresponding inode numbers are kept in the 
directories with the files; if 'tweren't so, El User would be skruud (less'n
he did a dump of the fs...).

>
>Jamie  ...  "Who was that Masked Interrupt?"
>Written On  Saturday, February 2, 1991  at  06:31:32am EST

You should be a bit more sure of architectures, of commands and of UNIX
in general before you post something like this.  The problem is NOT trivial
(how a '/' ended up in a filename on disk is beyond me).  The solution, by
comparison, is.

(I, on the other hand, should be a bit more sure that someone else hasn't
already posted the answer to this problem, but, at this point, oh, well...)

Please don't take this as a flame.  It wasn't meant as such.
-- 
thought:  I ain't so damb dumn!	| Your brand new kernel just dump core on you
war: Invalid argument		| And fsck can't find root inode 2
				| Don't worry -- be happy...
...!{ucbvax,acad,uunet,amdahl,pyramid}!unisoft!greywolf

lwj@cs.kun.nl (Luc Rooijakkers) (02/05/91)

In article <2338@nickerson.munsell.UUCP> jackal@nickerson.UUCP (Phil Hammar) writes:
>
>	This used to happen here quite often, usually because someone
>with a MAC would use GatorShare to write a file via NFS whose name
>included the date.  The easiest solution was to use the MAC to change
>the name to something without the '/'.  Then I would carefully explain
>to the user what they did wrong and why they would be publicly flogged
>if they did it again (restore really gets goofy if it is reading a
>file system which contain such names).

Somewhere in the GatorShare configuration is a box labeled "Illegal
characters in filename". If you just add the '/' to the characters in
this box, your users won't be able to create such files again. Of
course, you then have to explain to them why they cannot create files with
slashes in their name...

--
Luc Rooijakkers                                 Internet: lwj@cs.kun.nl
Faculty of Mathematics and Computer Science     UUCP: uunet!cs.kun.nl!lwj
University of Nijmegen, the Netherlands         tel. +3180652271

jfh@rpp386.cactus.org (John F Haugh II) (02/05/91)

In article <MARC.91Feb4134223@marc.watson.ibm.com> marc@arnor.uucp writes:
>An alternative is to make a new directory with the same parent as the
>bad one.  Then HARD link all the other files into the new directory.
>Then blow away the bad one.  You will probably have to unlink the bad
>directory to blow it away.  Having done that, you should fsck the file
>system to clean up.

This is a lousey idea.  By merely hard linking, and not moving, you
will have a large number of link counts which must be corrected when
the filesystem is cleaned.  The most painless method is to move all
the files and directories out of the directory with the bad entry,
unmount the filesystem, zero out the directory's i-node, fsck the
filesystem, remount, rename the new directory to the old name, then
move the file from lost+found to the new directory with a less
dangerous filename.

fsdb and adb are best left to people who already knew the answer to
this problem.
-- 
John F. Haugh II                             UUCP: ...!cs.utexas.edu!rpp386!jfh
Ma Bell: (512) 832-8832                           Domain: jfh@rpp386.cactus.org
"I've never written a device driver, but I have written a device driver manual"
                -- Robert Hartman, IDE Corp.

keinert@IASTATE.EDU (Keinert Fritz) (02/05/91)

I have been looking at a lot of the answers to how to get rid of a
file with a slash '/' in its name. Nobody yet has mentioned the very
simple answer I ran across some kind of newsgroup a year or two
ago.

I have never tried it myself, so it may not work, but it is so simple,
you might as well try it: apparently, emacs can handle it. Just go into
directory mode in emacs and delete the file. Rename should also work, I
would assume.

Fritz Keinert                             phone:  (515) 294-5128
Department of Mathematics                 fax:    (515) 294-5454
Iowa State University                     e-mail: keinert@iastate.edu
Ames, IA 50011

tchrist@convex.COM (Tom Christiansen) (02/06/91)

From the keyboard of murray@motto.UUCP (Murray S. Kucherawy):
:Actually, I had a file called "-l" this morning, which obviously doesn't
:work with "rm".  

    $ rm ./-l

This is in the FAQ.  This isn't wizardly talk.  Sigh.

--tom
--
"Still waiting to read alt.fan.dan-bernstein using DBWM, Dan's own AI window 
manager, which argues with you for 10 weeks before resizing your window." 
### And now for the question of the month:  How do you spell relief?   Answer:
U=brnstnd@kramden.acf.nyu.edu; echo "/From: $U/h:j" >>~/News/KILL; expire -f $U

dik@cwi.nl (Dik T. Winter) (02/06/91)

In article <19025@rpp386.cactus.org> jfh@rpp386.cactus.org (John F Haugh II) writes:
 > In article <MARC.91Feb4134223@marc.watson.ibm.com> marc@arnor.uucp writes:
 > >   ...    Then HARD link all the other files into the new directory.
Oh yes, how to do that if the directory name contains a '/'?
 >                             The most painless method is to move all
 > the files and directories out of the directory with the bad entry,
Same question here.
--
dik t. winter, cwi, amsterdam, nederland
dik@cwi.nl

alaw@oracle.com (Alvin W. Law) (02/08/91)

I remember reading an article in UNIXWORLD which deals with this exact
problem.  I forgot the exact issue, but it should be somewhere around 
Oct-Dec 90.


--

--
(.signature file under construction.  Expected completion mid-February 1991)

guy@auspex.auspex.com (Guy Harris) (02/11/91)

> > >   ...    Then HARD link all the other files into the new directory.
>Oh yes, how to do that if the directory name contains a '/'?

The assumption was, presumably, that the directory containing an entry
with a slash in it did not, itself, have a name containing a slash.  If
the directory in question has such a name, the way you do it is:

	1) apply the aforementioned "how to fix a file with a name
	   containing a slash" to that directory (this points out one
	   reason why you may NOT want to fix the problem by "clri"ing
	   the file - "clri"ing a directory and "fsck"ing will leave you
	   with a bunch of files in "lost+found" with cryptic names);

	2) now apply the fix to the broken file.

Recurse as needed....

> >                             The most painless method is to move all
> > the files and directories out of the directory with the bad entry,
>Same question here.

Same answer.

allbery@NCoast.ORG (Brandon S. Allbery KB8JRR) (02/12/91)

As quoted from <2902@charon.cwi.nl> by dik@cwi.nl (Dik T. Winter):
+---------------
| In article <19025@rpp386.cactus.org> jfh@rpp386.cactus.org (John F Haugh II) writes:
|  > In article <MARC.91Feb4134223@marc.watson.ibm.com> marc@arnor.uucp writes:
|  > >   ...    Then HARD link all the other files into the new directory.
| Oh yes, how to do that if the directory name contains a '/'?
|  >                             The most painless method is to move all
|  > the files and directories out of the directory with the bad entry,
| Same question here.
+---------------

clri the directory, then fsck.  The files will be reconnected in lost+found.
Of course, you'll lose the file names.

++Brandon
-- 
Me: Brandon S. Allbery			    VHF/UHF: KB8JRR on 220, 2m, 440
Internet: allbery@NCoast.ORG		    Packet: KB8JRR @ WA8BXN
America OnLine: KB8JRR			    AMPR: KB8JRR.AmPR.ORG [44.70.4.88]
uunet!usenet.ins.cwru.edu!ncoast!allbery    Delphi: ALLBERY

s082@brems.ii.uib.no (02/13/91)

There seems to be a rather lengthy discussion going on about slashes in
filenames,
how to get them there, and whether to ask questions about them...
Just one thing: Why would anyone want a slash (or any such character) a
filename in the first place?

-km

bzs@world.std.com (Barry Shein) (02/14/91)

From: s082@brems.ii.uib.no
>Just one thing: Why would anyone want a slash (or any such character) a
>filename in the first place?

Perhaps the file name was in Norwegian? :-)

(it's usually another machine, like a macintosh, using NFS to the unix
system and creating a file name like "Expense 12/2/91" which is legal
and common on macs.)

Doesn't norwegian use o-slash and all that?
-- 
        -Barry Shein

Software Tool & Die    | bzs@world.std.com          | uunet!world!bzs
Purveyors to the Trade | Voice: 617-739-0202        | Login: 617-739-WRLD

prc@erbe.se (Robert Claeson) (02/15/91)

In article <BZS.91Feb14043317@world.std.com> bzs@world.std.com (Barry Shein) writes:

>From: s082@brems.ii.uib.no
>>Just one thing: Why would anyone want a slash (or any such character) a
>>filename in the first place?
>
>Perhaps the file name was in Norwegian? :-)
.....

>Doesn't norwegian use o-slash and all that?

Yes, but it's o-slash as a single seven-bit or eight-bit character and
not an "o" followed by a slash.

-- 
Robert Claeson

Disclaimer: I represent myself and not my employer.

enag@ifi.uio.no (Erik Naggum) (02/15/91)

In article <BZS.91Feb14043317@world.std.com>, Barry Shein writes:
> From: s082@brems.ii.uib.no
> >Just one thing: Why would anyone want a slash (or any such character) a
> >filename in the first place?

> Perhaps the file name was in Norwegian? :-)

I fail to see the humor in this.

> Doesn't norwegian use o-slash and all that?

Norwegian does overload (as per ISO 646) [\]{|} into (ISO 8859-1 alert)
FXEfxe, but / remains /.  Norwegians may actually use - or . to
separate the parts of the date spec, so you might be better off with
one of us Viking descendants...  (Presently, I'm glad that we did not
inherit their Runes, even though the winter weather outside is
reminiscent of the Fimbulvinter we will see shortly before, or was it
after, the end of the world.)

My parents were fortunately smart enough to choose a family name
without any of the "national" characters, and to give me a name without
any of them, too, which might or might not have been caused by a quite
astonishing amount of foresight.  I've already decided on a dedication
line for any books I might produce:

	To my parents, who kindly avoided F, X, and E in my name.

Finally, I hope this makes it out with the ISO 8859-1 intact.  If not,
some of you might wonder what's so special with F, X and E.

--
[Erik Naggum]					     <enag@ifi.uio.no>
Naggum Software, Oslo, Norway			   <erik@naggum.uu.no>

Jenner@uswnvg.UUCP (Jenner) (02/16/91)

In article <1991Feb13.120201.13608@eik.ii.uib.no>, s082@brems.ii.uib.no writes:
> 
> There seems to be a rather lengthy discussion going on about slashes in
> filenames,
> how to get them there, and whether to ask questions about them...
> Just one thing: Why would anyone want a slash (or any such character) a
> filename in the first place?

Maybe they didn't.  How bout this sceniero.  

person types:   foo/bar and hits return
wanted to type: foo.bar and hit return

look at your keyboard.  it is possible.

"Users.  If we could only keep 'em off the machine."
					cedgman



	jenner .....................................dfpedro@uswnvg.UUCP

	      *Disclaimer?  You bet!  I speak for myself only.*

rauscher@remus.rutgers.edu (Rich Rauscher) (02/17/91)

>Maybe they didn't.  How bout this sceniero.  

>person types:   foo/bar and hits return
>wanted to type: foo.bar and hit return

>look at your keyboard.  it is possible.

Yeh, it's possible to type this but in almost all versions
of Unix, you'll just get an error 'No such 
file or directory' or something like it.  This will
happen whether you're in a shell or application.

-Rich
-- 
-------------
rauscher@rutgers.edu                RPO 5997 PO 5063, New Brunswick, NJ 08903
rauscher@PISCES                          Shakespeare learns Discrete Math:
{backbone site}!rutgers!rauscher                (2B | not (2B)) <=> TRUE

s090@brems.ii.uib.no (Kjartan) (02/20/91)

In article <BZS.91Feb14043317@world.std.com>, bzs@world.std.com (Barry
Shein) writes:
|> 
|> Doesn't norwegian use o-slash and all that?
|> -- 
Usually not in file names, but norwegian keyboards have 3 'extra' characters,
so if any of you see { , | , or } in a word it corresponds to what must be
written ae , oe and aa on 'ordinary' keyboards.

|>         -Barry Shein
|> 
|> Software Tool & Die    | bzs@world.std.com          | uunet!world!bzs
|> Purveyors to the Trade | Voice: 617-739-0202        | Login: 617-739-WRLD

-----
Kjartan Clausen                e-mail :  s090@brems.ii.uib.no
Institute of Informatics         or   :  fribyte@eik.ii.uib.no
University of Bergen           
Norway                         "Vi Veri Veniversum Vivius Vici"             

enag@ifi.uio.no (Erik Naggum) (02/21/91)

In article <1991Feb20.115554.3465@eik.ii.uib.no>, Kjartan writes:
   In article <BZS.91Feb14043317@world.std.com>, Barry Shein writes:
   |> 
   |> Doesn't norwegian use o-slash and all that?
   |> -- 

   Usually not in file names, but norwegian keyboards have 3 'extra'
   characters, so if any of you see { , | , or } in a word it
   corresponds to what must be written ae , oe and aa on 'ordinary'
   keyboards.

This, unfortunately, is dead wrong, bogus and doubly misleading.

Norwegian keyboards do _not_ have 3 _extra_ characters, and [\]{|}
are used in the national variant of ISO 646 for upper and lower case
AE ligature, O with slash, an A with ring above.  We do have a quite
peculiar keyboard layout in this country, but not "extra" keys as
opposed to any kind of "ordinary" keyboard (whatever that is).  The
two-letter transcribations of our national characters is almost
entirely a Norwegian 7-bit idiosynchracy with respect to terminals
with standard ASCII brackets, braces, backslash and vertical bar.

I would urge readers of comp.unix.wizards to ignore the article I
reply to.  It does not refer to Norwegian practice nor does its author
show any particular concern for accuracy with respect to the status of
national or international standards, which are in fact observed.

--
[Erik Naggum]					     <enag@ifi.uio.no>
Naggum Software, Oslo, Norway			   <erik@naggum.uu.no>

rob@aeras.uucp (Rob Rogers) (02/21/91)

In article <Feb.16.11.29.52.1991.575@remus.rutgers.edu> rauscher@remus.rutgers.edu (Rich Rauscher) writes:
>>Maybe they didn't.  How bout this sceniero.  
>
>>person types:   foo/bar and hits return
>>wanted to type: foo.bar and hit return
>
>>look at your keyboard.  it is possible.
>
>Yeh, it's possible to type this but in almost all versions
>of Unix, you'll just get an error 'No such 
>file or directory' or something like it.  This will
>happen whether you're in a shell or application.
>
>-Rich

I belive the original poster said the file was transferred to his machine
via NFS (from a different file system). Lots of other file systems don't 
think twice about a "/".
For instance, a Macintosh uses ":" (colon) as its magic-directory-marker.
Slashes (as well as spaces) in filenames are _very_ common.
(I teach people that come from Macs to UNIX. It takes a long time to get
used to _not_ putting a space in a name.)

Good 'ole DOS uses "\". It doesn't think twice about a / in a filename.

The whole world isn't UNIX, ya know (too bad).
-- 
	Rob Rogers
	Art Director, ARIX Computer Corporation
	{mips|sun|wyse|jade}!aeras!rob <> rob@aeras.UUCP <>
	73377.1017@compuserve.com <> GEnie=R.ROGERS10 <> AOL=MacGun

gwyn@smoke.brl.mil (Doug Gwyn) (02/22/91)

In article <ENAG.91Feb20213007@holmenkollen.ifi.uio.no> enag@ifi.uio.no (Erik Naggum) writes:
>I would urge readers of comp.unix.wizards to ignore the article I
>reply to.  It does not refer to Norwegian practice ...

But it was typed by a Norwegian!

I think both Norwegians described the same thing, but expressed it
differently.  Namely, there are additional ALPHABETIC keys (beyond
the 26 Latin characters), and are probably no keys for { | and }
graphic characters as such.

Note that standards for these matters have been evolving; existing
systems may not reflect any particular "latest" standard.

Anyone who has seen the wide variation around the world in typewriter
keyboard layouts should appreciate the situation.