From: no.top.post on
In article <hvqvf1$36o$1(a)news.eternal-september.org>, Tauno Voipio <tauno.voipio(a)notused.fi.invalid> wrote:

> no.top.post(a)gmail.com wrote:
> > Is this OS operating correctly ?
> >
> >> [root(a)localhost Legal]# ls *op
> >> ls: *op: No such file or directory
> >> [root(a)localhost Legal]# ls *op*
> >> Apr26Ltop Legal:Dictionarys Legal:Top.Bak Log.Bak
> >> Legal:Definitions LEGAL:SU LEGALXLA Routledge
> >> Legal:Definitions.Bak Legal:Top Log
> >> [root(a)localhost Legal]#
> >
> > Doesn't "*op" include "Legal:Top" ?
> > How the hell does it include "LEGALXLA" ?
> >
> > Does anybody else believe is subconcious knowledge, like what told me to try
> > `ls *op*` to find 'Legal:Top'
> >
> > While writing this, I think I discovered why Legal:Top is not seen in `ls *op`.
> > So why didn't they restrict the valid file-ID to avoid this problem?
> >
> > TIA.
> >
>
> What do:
>
> ls -al
> ls -al *op*
>
> show?
Dirs & files which have NO "op" in their names ?!
My subconcious seems to have once had problems since
'<string> ' looks like '<string>', and I'm used to ETHoberon,
where <space> is NOT a valid-char for file names.

I cd'ed to one of the subdirs, and got no such spurious
output for 'ls *op*'

And I: chroot <3 different partns> and it looked OK
excepr for showing:
'ls: <the file name>: No such file or directory'

?! why "No such file or directory" ?!

==TIA



From: Chick Tower on
On 2010-07-05, no.top.post(a)gmail.com <no.top.post(a)gmail.com> wrote:
> In article <hvqvf1$36o$1(a)news.eternal-september.org>, Tauno Voipio <tauno.voipio(a)notused.fi.invalid> wrote:
>>
>> What do:
>>
>> ls -al
>> ls -al *op*
>>
>> show?
> Dirs & files which have NO "op" in their names ?!
> My subconcious seems to have once had problems since
> '<string> ' looks like '<string>', and I'm used to ETHoberon,
> where <space> is NOT a valid-char for file names.
>
> I cd'ed to one of the subdirs, and got no such spurious
> output for 'ls *op*'
>
> And I: chroot <3 different partns> and it looked OK
> excepr for showing:
> 'ls: <the file name>: No such file or directory'
>
> ?! why "No such file or directory" ?!

I think Tauno was asking you to show the output of those commands, as
you did in your initial post.

Did you even read any of the other replies to your request for help?
Several people told you what's happening when you run your ls commands.

Why are you bringing chroot into this? You move around in partitions,
or between partitions, with cd. You can also include the directories
you wish to see the file listings in on the command line when using ls.
Perhaps a tutorial on using the Linux command line would benefit you.
You should be able to find many with your favorite search engine.
--
Chick Tower

For e-mail: aols2 DOT sent DOT towerboy AT xoxy DOT net
From: Tarkin on
On Jul 5, 3:47 am, no.top.p...(a)gmail.com wrote:
> In article <hvqvf1$36...(a)news.eternal-september.org>, Tauno Voipio <tauno..voi...(a)notused.fi.invalid> wrote:
>
>
>
> > no.top.p...(a)gmail.com wrote:
> > > Is this OS operating correctly ?
>
> > >> [root(a)localhost Legal]# ls *op
> > >> ls: *op: No such file or directory
> > >> [root(a)localhost Legal]# ls *op*
> > >> Apr26Ltop              Legal:Dictionarys  Legal:Top.Bak  Log.Bak
> > >> Legal:Definitions      LEGAL:SU           LEGALXLA       Routledge
> > >> Legal:Definitions.Bak  Legal:Top          Log
> > >> [root(a)localhost Legal]#
>
> > > Doesn't "*op" include "Legal:Top" ?
> > > How the hell does it include "LEGALXLA" ?
>
> > > Does anybody else believe is subconcious knowledge, like what told me to try
> > > `ls *op*` to find 'Legal:Top'
>
> > > While writing this, I think I discovered why Legal:Top  is not seen in `ls *op`.
> > > So why didn't they restrict the valid file-ID to avoid this problem?
>
> > > TIA.
>
> > What do:
>
> >    ls -al
> >    ls -al *op*
>
> > show?
>
> Dirs & files which have NO "op" in their names ?!
> My subconcious seems to have once had problems since
> '<string> ' looks like '<string>', and I'm used to ETHoberon,
> where <space> is NOT a valid-char for file names.
>
> I cd'ed to one of the subdirs, and got no such spurious
> output for 'ls *op*'
>
> And I: chroot <3 different partns> and it looked OK
> excepr for showing:
> 'ls: <the file name>: No such file or directory'
>
> ?! why "No such file or directory" ?!
>
> ==TIA

Recent distro's and/or kernels(?) will allow space(s) in filenames.
Much like Windows, apparently (human) readable file (and directory!)
names such as, "The Quick Brown", are valid, presumably to facilitate
interoperability.

try this:
$foo(a)bar: ls "The Funky Filename"

replace 'The Funky Filename' with your funky filename.

TTFN & HTH,
Tarkin
From: Chris F.A. Johnson on
On 2010-07-09, Tarkin wrote:
....
> Recent distro's and/or kernels(?) will allow space(s) in filenames.

All *nix filesystems have always accepted spaces in filenames. In
fact, the only characters *not* permitted in filenames are the NUL
(ASCII 0) and the slash (/).

--
Chris F.A. Johnson, <http://cfajohnson.com>
Author:
Pro Bash Programming: Scripting the GNU/Linux Shell (2009, Apress)
Shell Scripting Recipes: A Problem-Solution Approach (2005, Apress)
From: Kenny McCormack on
In article <89nv0nF6u6U1(a)mid.individual.net>,
Chris F.A. Johnson <cfajohnson(a)gmail.com> wrote:
>On 2010-07-09, Tarkin wrote:
>...
>> Recent distro's and/or kernels(?) will allow space(s) in filenames.
>
> All *nix filesystems have always accepted spaces in filenames. In
> fact, the only characters *not* permitted in filenames are the NUL
> (ASCII 0) and the slash (/).

They just have had the good sense not to exploit it.

Note that Windows is, in fact, quite a bit *more* restrictive than Unix
is, in this regard. The obvious example being that Windows forbids a
line feed in a filename (No flames, please, but I think we can agree
that this is a Good Thing). This makes it funny that some people think
that Windows brought the problem to the table - i.e, that Unix didn't
allow it and never had to deal with the problem until that icky Windows
thing came along and started besmirching our servers.

But of course (And yes, I'm now arguing against myself), it is true in a
way that Windows (*) caused the problem, since, as I said above, Unix
systems have always had the good sense not to use it (even though they
always had it...)

(*) And other "friendly GUI" systems, such as Mac. I don't mean to
completely single out Windows here.

--
(This discussion group is about C, ...)

Wrong. It is only OCCASIONALLY a discussion group
about C; mostly, like most "discussion" groups, it is
off-topic Rorsharch [sic] revelations of the childhood
traumas of the participants...