Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #177771 > unrolled thread

An Odd File Name

Back to article view | Back to linux.debian.user

Contents

  An Odd File Name "Martin McCormick" <martin.m@suddenlink.net> - 2017-02-13 18:10 +0100
    Re: An Odd File Name John Darrah <xyllyx@gmail.com> - 2017-02-13 18:20 +0100
    Re: An Odd File Name Greg Wooledge <wooledg@eeg.ccf.org> - 2017-02-13 18:20 +0100
      Re: An Odd File Name "Martin McCormick" <martin.m@suddenlink.net> - 2017-02-13 19:30 +0100
    Re: An Odd File Name Jude DaShiell <jdashiel@panix.com> - 2017-02-13 19:30 +0100
    Re: An Odd File Name David Wright <deblis@lionunicorn.co.uk> - 2017-02-13 20:00 +0100
      Re: An Odd File Name Jonathan Dowland <jmtd@debian.org> - 2017-02-14 10:40 +0100
    Re: An Odd File Name Patrick Bartek <nemommxiv@gmail.com> - 2017-02-14 01:20 +0100

#177771 — An Odd File Name

	I downloaded a file from a site using lynx and the file
name is "InstallingGRFromSource#Using-the-build-gnuradio-script.gz"
Actually, the double quotes are here for clarity but the name is
as it appears including the # sign.  Ls sees it and rm -i would
remove it if I let it but if I do:

gunzip InstallingGRFromSource#Using-the-build-gnuradio-script.gz

or

ls InstallingGRFromSource#Using-the-build-gnuradio-script.gz

bash can't find/see the file.

I am a bit embarrassed to ask this question because I have been
using unix for about 28 years and am well aware that certain
characters in file names such as blank spaces cause problems but
these are usually negated by either putting the whole file name
in double quotes or by escaping the troublesome character with a \ or backslash.

	While there is no whitespace character anywhere in the
name, there are several dashes and a # sign which is probably the
worst offender. I tried escaping the # symbol with a backslash
with no change and then I tried escaping all the dashes with
backslash characters as in \- and \# but commands referencing the
file by name all come up short. I also did try the whole name in
both single and double quotes.

	This is a teachable moment but I am not sure what else to
do other than remove all the other files in the directory and
then gunzip * which might work but that's sure going about things
the weird way rather than systematically. I did list the file by
using ls and piped that in to a file which I then removed all
names but the problem one and then used od -tx1 on the file name,
piping that to less so I could see if there were any 8-bit
characters or some other oddity, but the name was composed
only of the letters you see.

	By the way, gunzip does not have a -i flag like rm but
that thought crossed my mind.

	Since the name is long, I did make a short file with the
command such as ls or gunzip and the file name and then I typed

source thatfile

or sh thatfile so I did not type the command directly from the
command prompt but normally the source command is as if you did
type on the keyboard from the prompt.

	Any ideas for matching that name?

Thank you.

Martin McCormick WB5AGZ

[toc] | [next] | [standalone]

#177772

On 2/13/2017 9:09 AM, Martin McCormick wrote:
> gunzip InstallingGRFromSource#Using-the-build-gnuradio-script.gz

Just quote the filename like this:

gunzip 'InstallingGRFromSource#Using-the-build-gnuradio-script.gz'

-- john

[toc] | [prev] | [next] | [standalone]

#177773

On Mon, Feb 13, 2017 at 11:06:24AM -0600, Martin McCormick wrote:
> 	I downloaded a file from a site using lynx and the file
> name is "InstallingGRFromSource#Using-the-build-gnuradio-script.gz"
> Actually, the double quotes are here for clarity but the name is
> as it appears including the # sign.  Ls sees it and rm -i would
> remove it if I let it but if I do:
> 
> gunzip InstallingGRFromSource#Using-the-build-gnuradio-script.gz
> 
> or
> 
> ls InstallingGRFromSource#Using-the-build-gnuradio-script.gz
> 
> bash can't find/see the file.

The # character is only a comment indicator in bash when it appears
at the start of a word, not in the middle.  That's why ls and rm have
no problem with it.  Therefore bash has no problem with it, because
clearly bash is passing the filename intact to ls and rm.

If gunzip has a problem with it, then I would suggest you simply rename
the file.

[toc] | [prev] | [next] | [standalone]

#177775

	First, thank you to both responders. Next, I really
goofed. I forgot that gunzip normally removes the .gz file when
it runs so what I had in place of the .gz file was

InstallingGRFromSource#Using-the-build-gnuradio-script

without the extension. I didn't even miss it when I did rm -i *
so I was thinking nothing had happened.

	Some days, some of us are just absentminded. I always
feel really bad if that causes other people to waste their time.
The file name actually needed no specialtreatment at all and
gunzip just worked.

Again, thank you.

Martin

[toc] | [prev] | [next] | [standalone]

#177774

I only remember part of this unfortunately.  When a situation like this 
happens you got to get the file's inode number then reference it using 
that inode number and perhaps open it.  This topic was covered shortly 
in the Unix class I took back in 1990.  How to do the rest of it I think 
is done with find but don't quote me on that.

On Mon, 13 Feb 2017, Martin McCormick wrote:

> Date: Mon, 13 Feb 2017 12:06:24
> From: Martin McCormick <martin.m@suddenlink.net>
> To: debian-user@lists.debian.org
> Subject: An Odd File Name
> Resent-Date: Mon, 13 Feb 2017 17:06:46 +0000 (UTC)
> Resent-From: debian-user@lists.debian.org
>
> 	I downloaded a file from a site using lynx and the file
> name is "InstallingGRFromSource#Using-the-build-gnuradio-script.gz"
> Actually, the double quotes are here for clarity but the name is
> as it appears including the # sign.  Ls sees it and rm -i would
> remove it if I let it but if I do:
>
> gunzip InstallingGRFromSource#Using-the-build-gnuradio-script.gz
>
> or
>
> ls InstallingGRFromSource#Using-the-build-gnuradio-script.gz
>
> bash can't find/see the file.
>
> I am a bit embarrassed to ask this question because I have been
> using unix for about 28 years and am well aware that certain
> characters in file names such as blank spaces cause problems but
> these are usually negated by either putting the whole file name
> in double quotes or by escaping the troublesome character with a \ or backslash.
>
> 	While there is no whitespace character anywhere in the
> name, there are several dashes and a # sign which is probably the
> worst offender. I tried escaping the # symbol with a backslash
> with no change and then I tried escaping all the dashes with
> backslash characters as in \- and \# but commands referencing the
> file by name all come up short. I also did try the whole name in
> both single and double quotes.
>
> 	This is a teachable moment but I am not sure what else to
> do other than remove all the other files in the directory and
> then gunzip * which might work but that's sure going about things
> the weird way rather than systematically. I did list the file by
> using ls and piped that in to a file which I then removed all
> names but the problem one and then used od -tx1 on the file name,
> piping that to less so I could see if there were any 8-bit
> characters or some other oddity, but the name was composed
> only of the letters you see.
>
> 	By the way, gunzip does not have a -i flag like rm but
> that thought crossed my mind.
>
> 	Since the name is long, I did make a short file with the
> command such as ls or gunzip and the file name and then I typed
>
> source thatfile
>
> or sh thatfile so I did not type the command directly from the
> command prompt but normally the source command is as if you did
> type on the keyboard from the prompt.
>
> 	Any ideas for matching that name?
>
> Thank you.
>
> Martin McCormick WB5AGZ
>
>

-- 

[toc] | [prev] | [next] | [standalone]

#177776

On Mon 13 Feb 2017 at 11:06:24 (-0600), Martin McCormick wrote:
> 	I downloaded a file from a site using lynx and the file
> name is "InstallingGRFromSource#Using-the-build-gnuradio-script.gz"
> Actually, the double quotes are here for clarity but the name is
> as it appears including the # sign.  Ls sees it and rm -i would
> remove it if I let it but if I do:
> 
> gunzip InstallingGRFromSource#Using-the-build-gnuradio-script.gz
> 
> or
> 
> ls InstallingGRFromSource#Using-the-build-gnuradio-script.gz
> 
> bash can't find/see the file.
> 
> I am a bit embarrassed to ask this question because I have been
> using unix for about 28 years and am well aware that certain
> characters in file names such as blank spaces cause problems but
> these are usually negated by either putting the whole file name
> in double quotes or by escaping the troublesome character with a \ or backslash.
> 
> 	While there is no whitespace character anywhere in the
> name, there are several dashes and a # sign which is probably the
> worst offender. I tried escaping the # symbol with a backslash
> with no change and then I tried escaping all the dashes with
> backslash characters as in \- and \# but commands referencing the
> file by name all come up short. I also did try the whole name in
> both single and double quotes.
> 
> 	This is a teachable moment but I am not sure what else to
> do other than remove all the other files in the directory and
> then gunzip * which might work but that's sure going about things
> the weird way rather than systematically. I did list the file by
> using ls and piped that in to a file which I then removed all
> names but the problem one and then used od -tx1 on the file name,
> piping that to less so I could see if there were any 8-bit
> characters or some other oddity, but the name was composed
> only of the letters you see.
> 
> 	By the way, gunzip does not have a -i flag like rm but
> that thought crossed my mind.
> 
> 	Since the name is long, I did make a short file with the
> command such as ls or gunzip and the file name and then I typed
> 
> source thatfile
> 
> or sh thatfile so I did not type the command directly from the
> command prompt but normally the source command is as if you did
> type on the keyboard from the prompt.
> 
> 	Any ideas for matching that name?

You could try partial wildcarding, like:

$ ls *tall*build*

and if you succeed, then do type:

$ echo *tall*build* | od --endian=big -t x1

and try to reveal what the filename actually is by hex dumping it.

If you fail to match it, then you need a blunderbuss:

$ ls -1 | od --endian=big -t x1 | less

Now search for 0a (by typing /0a at less's prompt)
and, in the company of short filenames, your long one
will be delimited by two widely spaced 0a strings.

Here is what you're checking for:

$ echo ' InstallingGRFromSource#Using-the-build-gnuradio-script.gz' | od --endian=big -t x1
0000000 20 49 6e 73 74 61 6c 6c 69 6e 67 47 52 46 72 6f
0000020 6d 53 6f 75 72 63 65 23 55 73 69 6e 67 2d 74 68
0000040 65 2d 62 75 69 6c 64 2d 67 6e 75 72 61 64 69 6f
0000060 2d 73 63 72 69 70 74 2e 67 7a 0a
0000073

Perhaps there's something embedded in the name that doesn't display.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#177784

[Multipart message — attachments visible in raw view] — view raw

On Mon, Feb 13, 2017 at 12:49:35PM -0600, David Wright wrote:
> You could try partial wildcarding, like:
> 
> $ ls *tall*build*

This is often very useful, even to make typing awkward characters
easier. I often use ? rather than * to reduce the risk of accidentally
matching other files.
 

-- 
Jonathan Dowland
Please do not CC me, I am subscribed to the list.

[toc] | [prev] | [next] | [standalone]

#177779

On Mon, 13 Feb 2017 11:06:24 -0600 "Martin McCormick"
<martin.m@suddenlink.net> wrote:

> 	I downloaded a file from a site using lynx and the file
> name is "InstallingGRFromSource#Using-the-build-gnuradio-script.gz"
> Actually, the double quotes are here for clarity but the name is
> as it appears including the # sign.  Ls sees it and rm -i would
> remove it if I let it but if I do:
> 
> gunzip InstallingGRFromSource#Using-the-build-gnuradio-script.gz
> 
> or
> 
> ls InstallingGRFromSource#Using-the-build-gnuradio-script.gz
> 
> bash can't find/see the file.
> 
> I am a bit embarrassed to ask this question because I have been
> using unix for about 28 years and am well aware that certain
> [snip]

Is the file in your username's PATH?  Or enter full path to file.  Or
just CD to where the file is, maybe, preceeding the filename with ./

B

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web