Kubuntu/openSUSE (either one).
[Edited to correct grep switch and added cd to script to show how we know PWD. -rs, jan 15, 2012]
How do I create a clickable script that can tell if I'm running as superuser to do such things as mounting and unmounting an iso that is in the current directory?
One clickable per iso is fine for starters. Making the iso selectable is easy after that, so let's keep it simple.
Here's what should (famous last words) already work.
To re-run the application after automatically su-ing or sudo-su-ing we may need to extract the app name and derive the current directory in the script as follows.
cd `dirname "$0"`
[All the above are in quotes so paths with spaces will not break and the reason for explicitly creating the full path is because the app may alternatively be launched from the teriminal and under certain conditions PWD may get lost, not to mention the PATH if dot ('.') is in your path, which I do myself.]
Here are the elements of the problem.
1. If we are already superuser we do not need to 'sudo su' or 'kdesu' or kdesudo, in order to mount the iso in the same folder with the clickable script program. As a clickable app it may be run in any capacity (su or otherwise).
[I am aware of xdg-su. It's a script. See what it does to rewrap the other kluges before you jump the gun here.]
2. The script must 'execute' when it's clicked on (either on the desktop or in a filemanager), even if this requires a new extension and file association for the file type.
The extension '*.exec' rather than '*.sh' is perfectly legit, and makes it clear as to purpose and properties of the program. It would also be nice if it ran when the ENTER key was activated when the file is highlighted. But if that's that just a bit "too retro", clickable would at least PASS the functionality test.
3. If the iso is already mounted, we need to see a notice to that effect.
I do NOT want to have to drop down to a terminal to run these scripts. Never did before and I will not now.
Furthermore the commandline "noise" penalty and extra code to suppress it requires recurring effort (code duplication) that should have been addressed upstream once and for all.
A bit of a rant follows, but the plea for help above remains.
As we speak, modern linuxes are becoming more and more user-unfriendly, making us more and more dependent on developers of gui apps to do these things for us, even if the job could be done in two lines of bash script if they'd just quit dumbing our systems down.
Case in point: See "xmessage -help". Better yet, see "kdialog --help". Both are interactive and both are becoming more and more inaccessible with each new misguided generation of kde.
I am not sure about Gnome, but I expect they are making the same or similar errors. Why? (Because we let them?)
Perhaps you've heard complaints about newer kde version that read something like this: "KDE3 was the last decent version".
There is certainly some truth to that. But ususally we don't hear the details of the complaint. What exactly is kde doing wrong?
Let's remedy that omission, at least in part, right now.
Linux is supposed to be a bunch of tools that work well together. We should all agree on that but if not pry open the docs for 'binutils' and get up to speed on this.
In kde we even see kde tools that don't work well with other kde tools and the situation seens to be getting WORSE every time around.
I had to revert to Kubuntu 11.10 because 12.4 is unusable for programming -- it wipes out PATH and LD_LIBRARY_PATH so that I can't test an app in a sandbox with it and even my attempts to 'read' my user's .bashrc file (a complicated process involving using 'sed' to pull out the text because the script apparently will NOT RUN from the su/sudo wrapper) in order to extract those values textually doesn't work consistently. (both the dot.profile and the *rc files need to be picked to pieces, and it' just a mess.)
This could be probably be addressed easily enough on the Kubuntu side despite what KDE is doing. But PATH and LD_LIBRARY_PATH env vars should never should have been wiped clean. How did that get past the developers?
Credit where it's due, the plasma desktop is a knockout. But the lack of concern about making kde as much a part of linux as linux is a part of kde is apalling.
Need another example?
Would you be surprised to know that some of the warnings seen on the commandline when you launch, say, konqueror, dolphin, or kate are about bugs that apparently no longer exist?
Non existent bugs noise on the commandline.
The warning issued for kxmlguiclient not removing widgets from the factory before destruction is in the destructor which DOES remove (aks "forget") them from the factory first.
[Seen that one? It's rather ominous sounding. Could leak standalone popups and cause crashes?]
Absurd? Sure looks like it. But why is kde treating our commandline like their own personal unemptied recycle bin?
Why does KDE treat MY commandline like a communication network to/from other developers and not even remove warnings that apparently no longer apply?
[C/C++ Programmers: That seemingly self-negating warning is issued at around line 100 in the code for kxmlguiclient.cpp, which you can see if you are able to extract sources on your kde system anymore. And if KDE wants meaningful bug reports or even explicit non-bug non-fixes, they'd better make sure their users CAN STILL COMPILE ON THEIR SYSTEMS, don't you think?]
Why is that commandline noise, the warnings and errors still flying all over our terminals after all of these years? Is it because "normal" users don't notice? (One-size-fits all? Well, then let's dump linux altogether and get with the program, eh?) Or is it that we are being conditioned to accept absurdity; utter stupidity, the worst of the Windows philosophy, as long as these absurdities appear to be intentiional.
[re. Intentional Absurdity (Another 'aside'. You can take it, don't pretend you can't) ;-)
kdesu usage is amply documented.
If you are already superuser it will crash and take down drkonqi with it. And if you are allowed to launch apps from the commandline using kdesu or some other su wrapper, why in the WORLD do they seem to expect us NOT to use the commandline and especially customized clickable script programs to launch them as normal users?
Here's a replacement for 'edit' that uses kate (a 'new' instance) and can take the output from a 'grep -in' search, and open the file to the exact line where the text is found.
args=`echo $@ | sed 's|[:]| --line |; s|[:].*| |g;'`
launch "kate -n $args"
What launch (above) does is something like windows' 'start' command. In this context it's very similar to 'nohup $@ >/dev/null 2>&1 &' and don't forget the last ampersand. Or just remove 'launch' if you don't mind your terminal being tied up until the editor exits.
Why has kde foisted upon us a new special syntax for su/sudo? Is that supposed to be a security feature? Or is it just arrogance, the appearance of security, but having the as it's only effect the making of commandline tools and especially compilation less accessible to the (alleged) owners of the linux/kde system.
Any hacker with root password can still do anything the owner can do -- which is admittedly less and less, but wait....
That's a bit of a disconnect. The developers are now the only ones that can do more than even the owners of the computer that runs their kde system. Isn't that one of the complaints about Windows? What in the world are we thinking?
That's the point, folks. Do you know THEIR social security numbers? What guarantee do you have that they don't know yours. What is PackageKit doing behind your back? Why is tracker creating tens of megs or in my case hundreds of megs of useless information. That ancient technology in "locate" works better, faster, more efficiently, and doesn't hog cpu time creating indexes for 4 or 5 gigs of source files that are constantly changing.
Who is monitoring the stuff that your system is built from?
"Open" as in "Source" would imply that you have not only a right to know that the sources match what is in your system, but that you have the expectation that many people would indeed know what is in "My Computer" yet it seems that nobody can look into them even if they have in the past had all the tools and expertise to do so.
Download the source for libffi45 if you think I'm kidding. That should be a 280K file, not 60 Megs.
That version of libffi does not exist anywhere except at openSUSE and what you end up downloading is
gcc, not libffi. If you look around you'll see that this is supposedly the "standard" sources for that library.
That's certainly not the only example of uncaught source/binary incongruency, it's only the worst one I've seen so far. How is it that even after I have mentioned this to admins at the forums and even to developers that the file is still there?
Arrogance? Nobody will notice?
Well, guess WHAT!?
But back on the ranch...
As long as the spec is ABSURD, it must be fine. grub now clobbers older grub bootloaders but Windows? No prob.
Let's pick on Kubuntu too. It's their turn next. Here's another long-standing problem that, at least in this case, can be be remedied very easily. If they are willing to do it.
Introducing The Kubuntu Non-Bug:
Pthreads is NOT missing in kubuntu. DASH is the default shell for debian and cmake expects BASH. I wanted to mention that again here since it is one of the few hangups for compiling kubuntu apps (at least up to v. 11.10) and the problem can be seen all over the internet with few if any clear 'fixes' for that issue.
cd into /bin and 'ln -sf bash sh' at least for the duration of the compile job and it should all compile as expected.
Other makefiles may also have issues with 'dash' and in fact pthreads.so (an ld script) may not even work with dash. Dunno for sure.
For those unaware of the importance of this seemingly minor point of 'user preference' and to point out the crazy trend in supposedly "open source" these days;
1. kde is dependent on cmake.
2. Kubuntu is dependent on kde.
3. Kubuntu uses the dash shell as the default, as inherited from debian.
Result: Kubuntu's default shell is incompatible with their default build system. Many, if not most PROGRAMMERS, will even throw up their hands and just download the opaque binary. That was not an easy nut to crack.
"Open" becomes "Closed" source, just like that.
The "linux way" used to be that these tools worked together.
Regardless, I'd be satisfied to regain just a little bit of the former functionality of my "old linux" if anyone knows how to do it. See the three points at the top.