Dolphin starts programs with a wrong current directory

[Duncan]

Nikos Chantziaras posted on Thu, 10 Dec 2009 11:02:08 +0200 as excerpted:

> If I send someone a tar with a directory in it, a script and a few
> files, why shouldn't the person receiving it be able to simply double
> click the script instead of opening a CLI, going to the directory and
> start the script from the CLI?  Why should he have to "install" the data
> files first only to remove them again later?  Only because of Dolphin?

That's easy enough, assuming by script you mean bash script.  $0 contains 
the name of the executable including its path, and there are the various 
${var-action-pattern} string manipulation builtins, and assuming no weird 
stuff (/ that aren't directory separators, but quotes where appropriate 
should take care of embedded spaces, etc), the script can easily do 
something like this (make sure your client is keeping the wrap,
monospace font for display will help as well):

---8><---><8---

#!/bin/bash
# That's a standard "shebang", calling bash at the standard
# location.  If something else is initially called to
# interpret the script, the above /should/ call bash instead.

# What was I called as?
me=$0

# Get my path, assuming / as the directory separator.
# These operators can be used in ${var-op-pat} constructs to
# return the string with the matching pattern removed:
# #  is shortest match pattern at the left  of string
# %  is shortest match pattern at the right of string
# ## is longest  match pattern at the left  of string
# %% is longest  match pattern at the right of string
# On the US keyboard layout at least, # and % are just
# left and right of the $ var indicator, making them
# easy to remember.  Similarly, the doubled form is
# longer than the single, for longer matches.
# Do remember it's the match that's /removed/.
# When I first started, that seemed like negative
# logic to me as I wanted the match /saved/, but that's
# usually possible going from the other end.  Or use
# sed/grep/cut or the like for more complicated stuff.
mypath=${me%/*}

# Do something with a file at that path.
cat "$mypath/datafile"

---8><---><8---

Now the script can be called from the user's home dir,
or anywhere else the user wishes.  While this looks a bit
complicated from a user perspective, the presupposition was
that a script was used.  If someone's writing a script,
they should know how to script (or how to RTFM or google
it, at least), and the above without all the commentary
would likely be written as a single line of code
(plus the shebang line), as so:

cat "${0%/*}/datafile"

That's not significantly longer than the command assuming one's
starting in the same dir, yet MUCH more reliable:

# Don't just do this, unless you've cd-ed to the path first.
cat datafile

(FWIW, I initially learned bash using the bash appendix in the
back of the "Linux in a Nutshell" book, working out and
rewriting into more modular form the (then) Mandrake initscripts.  
Initscripts are generally well self-documented, with at least the primary 
paths well tested and honed over years of development, so they're the 
ideal candidate for someone wishing to learn how bash scripting is 
/really/ used in the real world.  Just be sure you make backups and know 
how to boot from your recovery CD/thumbdrive/alternate-root-partition/
whatever to put back the backups, if you screw things up while 
experimenting! =:^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

___________________________________________________
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.