Re (2): What am I doing wrong ?
in [Slackware]
|
Prev: Downloading 13.1?
Next: apache and logrotate
From: no.top.post on 5 Jul 2010 03:47 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 6 Jul 2010 13:17 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 9 Jul 2010 02:30 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 9 Jul 2010 02:47 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 9 Jul 2010 15:01
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... |