Prev: HOW CAN I HACK $5000 FROM PAYPAL WATCH VIDEO.
Next: Fixing stdin inside a redirected loop...
From: John DuBois on 21 Jul 2010 12:18
In article <4dfcad34-0283-46f7-9b04-8f7721debd78(a)q35g2000yqn.googlegroups.com>,
steven_nospam at Yahoo! Canada <steven_nospam(a)yahoo.ca> wrote:
>On Jul 19, 3:44�pm, gaze...(a)shell.xmission.com (Kenny McCormack)
>wrote:
>> Outer problem: I have an app that only works if fed a full path to the file.
>> It will not work with a relative path (known, documented limitation in
>> the app)
>>
>> So, I setup a shell alias to call the app, prepending the value of $PWD
>> to the filename argument passed. �This works fine - especially in the most
>> common use case, which is passing in a simple file name (to invoke the
>> app on a file in the current directory) - but I have a couple of niggling
>> issues with this:
>>
>> � � 1) It won't work right if I happen to invoke the alias with an absolute
>> � � � � path. �Because then, the app would get something like:
>> � � � � � � /path/to/here/path/from/root/file
>> � � � � So, it would be nice to plug this small hole.
>
>I'm sure there are probably easier ways, but here is what I would
>propose.
>
>You could check to see if the passed string starts with a "/". That
>immediately tells you it is absolute pathname.
>
> MYPATH=/home/fred/filename1
> if test "$(echo "${MYPATH}" |cut -c1)" = "/"
> then
> # dont add path...it is already absolute
> fi
>
>However, this logic is not foolproof. If someone puts spaces at the
>beginning when entering a full pathname, you may get the first
>character as a space. Or worse, if they try to enter these paths:
>
> ./saved_files/myjunk
> ../reports/sample.report
>
>So if you do some sort of logic like this, you will want to make it
>more robust and check/address this type of thing.

If the problem is nothing more than an app that insists on an absolute path -
that is, you don't care how clean it *looks* - then simply testing for a
leading / and prepending $PWD/ if there is none is sufficient.

Spaces in filenames are legal. Leading spaces in a path are part of the path.
If you have a particular input mechanism that is subject to spaces being
erroneously included, then sure, remove them.

Embedded . and .. components are perfectly fine in a path and won't result in
the path resolving incorrectly. If you're in the directory /foo/bar, and
specify the path ../baz, then $PWD/../baz (/foo/bar/../baz) will give your app
exactly the file you want.

There are many instances in my ksh programs of e.g.:

[[ $path != /* ]] && path=$PWD/$path

John
--
John DuBois spcecdt(a)armory.com KC6QKZ/AE http://www.armory.com/~spcecdt/
From: steven_nospam at Yahoo! Canada on 21 Jul 2010 16:17
On Jul 21, 12:18 pm, spce...(a)armory.com (John DuBois) wrote:

> Spaces in filenames are legal.  Leading spaces in a path are part of the path.

Never said they weren't. While adding spaces in a filename or even as
the first character in a filename is possible, it certainly is frowned
upon by many people who have worked in historical versions of UNIX.

Even honored schools like Stanford University are teaching students to
treat special characters and spaces as somewhat taboo in UNIX system
filenames, as it can cause random odd behavior or problems. From one
of their websites: "....it is best if you do not use the following
characters in a UNIX file name: *&%$|^/\~ or - as the first character
of a file name, because those characters are interpreted by UNIX as
commands.You can use spaces in UNIX file names, but it is not
recommended since you will then have to surround the file name with
quotes whenever you want to use that name. For example, if you want to
refer to the file Program #2, you would have to write "Program #2",
otherwise UNIX will try to interpret the #2 part as a command or the
name of another file...."

> There are many instances in my ksh programs of e.g.:
>
>     [[ $path != /* ]] && path=$PWD/$path

Totally agree. That is a nice and compact way of doing the basic check
I had suggested with the if..then..else..fi sample Korn Shell code.

I don't see the problem with making the user-written code a few lines
longer to make it work better or address the issue that was brought
forward. Theoretically, this "code" will only be accessed when one
person tries to save their file, so it's not like it is adding several
time cycles on the CPU. John's one-liner above certainly works better
than just prefixing $PWD to everything, but it's the OP's prerogative
to use whatever he decides is best (or easiest) for him and his
users. ;-)


From: Janis Papanagnou on 22 Jul 2010 03:01
steven_nospam at Yahoo! Canada schrieb:
> On Jul 21, 12:18 pm, spce...(a)armory.com (John DuBois) wrote:
>
>> Spaces in filenames are legal. Leading spaces in a path are part of the path.
>
> Never said they weren't. While adding spaces in a filename or even as
> the first character in a filename is possible, it certainly is frowned
> upon by many people who have worked in historical versions of UNIX.

....ITYM, by people who don't use clicky-clacky GUIs but rather use
the powerful command shell.

Has the behaviour of "historical versions" changed since then? Which
I think was, that everything but / can be used in a file name (and
that the names . and .. are treated special), and, that the shell(s)
delivered with UNIX use specific characters in her language syntax
(like any other text based programming languages do).

>
> Even honored schools like Stanford University are teaching students to
> treat special characters and spaces as somewhat taboo in UNIX system
> filenames, as it can cause random odd behavior or problems.

"Random"?

> From one
> of their websites: "....it is best if you do not use the following
> characters in a UNIX file name: *&%$|^/\~ or - as the first character
> of a file name, because those characters are interpreted by UNIX as
> commands.You can use spaces in UNIX file names, but it is not
> recommended since you will then have to surround the file name with
> quotes whenever you want to use that name. For example, if you want to
> refer to the file Program #2, you would have to write "Program #2",
> otherwise UNIX will try to interpret the #2 part as a command or the
> name of another file...."

(Their explanation is inaccurate in several places, unfortunately.)

I wonder why they didn't mention the use of control-characters, BTW.

Janis

>
>> There are many instances in my ksh programs of e.g.:
>>
>> [[ $path != /* ]] && path=$PWD/$path
>
> [...]
From: John DuBois on 22 Jul 2010 10:58
In article <262d555d-09ee-4d28-93cf-27d252984a11(a)t10g2000yqg.googlegroups.com>,
steven_nospam at Yahoo! Canada <steven_nospam(a)yahoo.ca> wrote:
>On Jul 21, 12:18�pm, spce...(a)armory.com (John DuBois) wrote:
>
>> Spaces in filenames are legal. �Leading spaces in a path are part of the path.
>
>Never said they weren't. While adding spaces in a filename or even as
>the first character in a filename is possible, it certainly is frowned
>upon by many people who have worked in historical versions of UNIX.

Avoiding spaces in filenames you generate is one thing. Writing a script that
treats spaces in a user-input filename as invalid is quite another. If you
accept a user-input filename that contains spaces as valid, then simply
prepending $PWD to non-absolute paths will always give you a correct version of
the path the user intended. A method that fails on, rejects, or alters paths
that contain spaces will not.

>> There are many instances in my ksh programs of e.g.:
>>
>> � � [[ $path != /* ]] && path=$PWD/$path
>
>Totally agree. That is a nice and compact way of doing the basic check
>I had suggested with the if..then..else..fi sample Korn Shell code.
>
>I don't see the problem with making the user-written code a few lines
>longer to make it work better or address the issue that was brought
>forward.

The issues that were brought forward were specifically 1) How to deal with an
absolute path (which the above does), and 2) whether there was a "better, more
built-in way to do this" - thus the demonstration of how to do it (in modern
shells) without using any externals.

John
--
John DuBois spcecdt(a)armory.com KC6QKZ/AE http://www.armory.com/~spcecdt/
From: steven_nospam at Yahoo! Canada on 22 Jul 2010 11:39
On Jul 22, 3:01 am, Janis Papanagnou <janis_papanag...(a)hotmail.com>
wrote:

> ...ITYM, by people who don't use clicky-clacky GUIs but rather use
> the powerful command shell.
>
> Has the behaviour of "historical versions" changed since then? Which
> I think was, that everything but / can be used in a file name (and
> that the names . and .. are treated special), and, that the shell(s)
> delivered with UNIX use specific characters in her language syntax
> (like any other text based programming languages do).

When UNIX first appeared on the scene in early 1970's, you could only
have 14 character filenames, because directory entries were 16-bytes
long and reserved two bytes for the i-node. By the 1980's they had
changed the standards to allow for longer names and additional
characters in file names. Of course, people who were used to the
original standards stayed with that standard of not using special
characters (including control characters), other than perhaps letting
their filenames get longer. I believe where I have seen the use of
spaces and special characters more often is (as you pointed out) when
the GUIs started coming out, and especially in LINUX platforms on PCs.
Anyone used to Windows naming conventions now pretty much use spaces
and whatever characters they like.

I've worked with many different people in a variety of UNIX platforms,
and I've heard plenty complain about the coding in an application they
are using when a filename suddenly has an unexpected character
(unexpected by the application) and as a result, avoid using any
special characters.

Random? I mean a cleanup utility that deletes files in the wrong place
(or the wrong file) because a space, question mark, or asterisk was
added in the name. Programs or sub-programs that return error codes
because they treated a filename containing a space incorrectly as two
or more files rather than one. That sort of thing. Are you telling me
you've never had a program on a UNIX platform behave in a manner that
was unexpected because of a character that was used in a filename?
Perhaps something using find or xargs command?

Yes, it is possible to simply say "that's not the fault of the person
naming the file, we should force developers to make their programs
more robust!". I totally agree with that. But that's easy to say if
you are using a proprietary package and can tell your developers to
fix it. If you bought a third-party package a few years back, have no
access to the source code, and you are now out of the support window,
not quite as easy to address.

Suffice it to say that if you don't account for the special characters
like spaces, it is possible (and likely) to have problems with saving
the file. But I think we are off topic a bit, and the OP already said
he is going to make due with what he has. I'll just keep avoiding
these characters, and you can keep clicky-clacking. ;-)


First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: HOW CAN I HACK $5000 FROM PAYPAL WATCH VIDEO.
Next: Fixing stdin inside a redirected loop...