Prev: HOW CAN I HACK $5000 FROM PAYPAL WATCH VIDEO.
Next: Fixing stdin inside a redirected loop...
From: Kenny McCormack on 19 Jul 2010 15:44
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.

2) I'm just curious if there is a better, more built-in way to do
this - some shell tool (something along the lines of basename)
maybe.

--
Just for a change of pace, this sig is *not* an obscure reference to
comp.lang.c...

From: steven_nospam at Yahoo! Canada on 19 Jul 2010 17:17
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.
>
>     2) I'm just curious if there is a better, more built-in way to do
>         this - some shell tool (something along the lines of basename)
>         maybe.
>
> --
> Just for a change of pace, this sig is *not* an obscure reference to
> comp.lang.c...

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.


One trick I think might work for you is the following:

#!/bin/ksh
echo "Enter pathname: \c"
read MYPATH
MYFILE=$(basename ${MYPATH})
if test "${MYFILE}" = "${MYPATH}"
then
FULLPATH=$(pwd)/${MYFILE}
else
FULLPATH=$(echo "$(cd $(dirname ${MYPATH}); pwd)/$(basename $
{MYFILE})
fi
echo "${FULLPATH}"
# END #

If the person only supplied a filename, then the basename will be the
same as the filename. So just set the path to $(pwd).
Otherwise, use the else logic.

The dirname portion gets handled first, and strips off the filename
leaving any path that was provided. The cd goes into that path, just
to obtain the value for pwd in that area. That gives full directory
pathname, no filename. Then we add the filename on the end.

This is untested, so please try it out a bit before implementing it.

Steve






From: Ben Bacarisse on 19 Jul 2010 17:49
gazelle(a)shell.xmission.com (Kenny McCormack) writes:

> 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.
>
> 2) I'm just curious if there is a better, more built-in way to do
> this - some shell tool (something along the lines of basename)
> maybe.

One way might be to

cd "$(dirname "$1")"
run-app "$(pwd)/$(basename "$1")"

You could always cd back, but this is probably a sub-shell so there is
no need.

--
Ben.
From: Rikishi42 on 19 Jul 2010 17:57
On 2010-07-19, Kenny McCormack <gazelle(a)shell.xmission.com> 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.
>
> 2) I'm just curious if there is a better, more built-in way to do
> this - some shell tool (something along the lines of basename)
> maybe.
>

How about something like:
- take note of current path
- cd to relative path (but do you have the rights ?)
- put value of pwd in a variable
- go back to original dir
- run app with variable



--
When in doubt, use brute force.
-- Ken Thompson
From: Kenny McCormack on 19 Jul 2010 20:14
In article <sbueh7-821.ln1(a)murmur.very.softly>,
Rikishi42 <skunkworks(a)rikishi42.net> wrote:
....
>How about something like:
>- take note of current path
>- cd to relative path (but do you have the rights ?)
>- put value of pwd in a variable
>- go back to original dir
>- run app with variable

Yeah, that's kinda where we seem to be heading with this.

However, ...
1) It's not really worth that much code. As I said, what I have now
works well enough. The goal was to reduce the amount of
user-written code, not increase it. I was hoping for a cute
built-in (and see below).
2) The shell in question is actually tcsh, not Bourne-ish.
3) What I'm really looking for is something like the DOS (Yeah, try
to control yourselves, boys) INT 21/AH=60 "fully qualify" API.
In those old days, you could pass it just about anything, and it
would return the fully qualified pathname. Was quite useful.

Re: #3 above, I seem to remember that Linux did have something like
that, but (obviously) I can't remember any details. In any event, a
Linux-specific solution would be more than welcome.


--
(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...

 |  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...