Need To Regain Lost Functionality (re.New KDEs)
 

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"`
APPNAME=`basename "$0"`
CURDIR="$PWD"
APPPATH="$CURDIR/$APPNAME"

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

------------------
#!/bin/sh
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.
http://software.opensuse.org/search?...ude_debug=true

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.

Thanks.

Hi,

What you want for isos exists somewhere as dolphin extension.

Those complains like "kde3 was the last decent version" "I want my bottom-panel back in Gnome3"
are the stupid complains of people which are not willing to make efforts , but need to install always the bleeding edge last testing version of every piece of software the get aware of .

Debugging output in a terminal is there for a good reason.

If you are not able to set PATH and LD_LIBRARY_PATH you shouldn't call yourself "programmer".
Reverting a distro for this and crying for developers to change the behavior *you* don't like, is ridiculous.

The abusive use of su or sudo is an Ubuntu madness.
If you want a distro which doesn't go the windows way and treat the user as an idiot who shouldn't touch this and that find a better one like gentoo or Slackware.

A "su" shell has it's limitations. Some would fall if you'd use simply "su -"

Many programming/compiling/development tools are made for a proper root enviroment and not to be invoked by sudo etc.

A proper chroot enviroment and a basic understanding of shell programming can help a lot.

And for anything else there's the maybe most repeated sentence in the (linux)-world:

If you don't like it, don't use it

So?

Of course it's there for a good reason. I read it all the time.

Doesn't everyone?

You haven't seen it. KDE developers apparently haven't seen it either. If they had seen it, they'd have removed the warnings about stuff that's already been fixed and they'd fix the stuff that's still broken, some of which has apparently been broken for like five years or something.

I set it. They unset it. Where to next, Cap'm?

Same goes for forum posts.

First, let's see how to make a clickable script. The advantages of a clickable script over a desktop icon is that it can be made relative to the current folder so that if the folder moves the program can still find where it was launched. Additionally it knows the name of the program/script that is running.

Let's do some poking around.

file: clickme.exec [chmod +x <filename> or add executable to properties]
The above is an example of a gui app that can be written in just a few lines of shell script.

Click on the file and make sure it runs.

If it doesn't run, you may TRY to add filetypes with .exec extensions to the x-executable types (in the file associations menu) and open them with '/bin/bash -c' or you may need to create a new 'runner' application that can take the name of a file and execute it along with it's arguments and make that the default application to "open" these files with.

[This extra step is one of the issues I have with newer linuxes. Older ones not only read the file extension ala DOS, but also check the first few bytes of the file (the signature of the file type) to determine its type and properties.]

In any case, it should be possible to execute it without opening a terminal.

Run as normal user CLICKED ON or executed from the commandline.

Run as su # enter password and typed from the commandline
Run as su - # and typed from the commandline with full path to the file
Works for openSUSE, doesn't work for Kubuntu
Run as sudo su # and typed from the commandline with full path to the file.
Works for Kubuntu, doesn't work for openSUSE

We see from the above that PWD is preserved in the environment with 'su' and 'sudo su', as it is for a normal user, but 'su -' (with the dash) changes PWD to root's home and if not changed in the script would have no idea where the application is supposed to run.

The point being that there are several differences in the way su works even before we toss in the gui wrappers such as kdesu, kdesudo, xdg-su, and so forth. Also, it turns out we do not need a wrapper for a script-based gui application such as this one.

Question #1 was how can we run this as superuser, relaunching itself after obtaining root permissions if we clicked on it as a normal user.

Let's back up for a moment here. Nobody's in a giant rush to get to the goodies are they? :-)

Pls actually try this if it doesn't look dangerous to you, or you may not understand why this is truly SUCH A BIG DEAL!

In the context of this thread, let's make sure relying on desktop icons isn't going to do everything we need to get done in our linuxes, though in truth we don't care. There was no good reason for KDE to break older apps. I.e., this will work in older KDE's. In the latest KDE versions they may not.

Copy and past this to a textfile on your desktop named konsole.desktop
[That's another way to make the desktop icons and it's arguably easier than the menu-ed method, and it certainly ends up significantly smaller.]

When it runs, what does it think PWD is?

It thinks it's "Documents"!

Change the Exec line to this...
and you'll have a terminal that opens when you click on it that is running where you clicked on it, right on your Desktop where you can see it's outputs when it is creating text files, etc.

But if you move that file, it will still open on the Desktop.

With a script-based gui program, consisting of even fewer lines, the same thing could be done like this (below) and it would always open in the folder where you clicked on it, even if it's moved.

Copy this to a text file named konsole.exec and change the properties to make it executable.
Spaces in paths = OK.

Move it to a new folder and click on it there. Click on it. Do NOT run it in a terminal for this demo. Verify that it knows where it was clicked on, which is where you want to do your terminal work with a tremendous collection of tools that many new linux users don't even know we have.

Justification for a script-based app here Established [\,]

Fair enough? :-)

--------------------

Addenda:

The desktop type files are better in some contexts. They look nicer for one thing. But they do NOT replace the functionality of a simple home made shell program, and as KDE continues to move toward withdrawing support for these simple scripts (I assume it's kde making these files un-executable) more and more new linux users will never know what they're missing.

If you are behind in your KDE updates there's a very good chance that both of those programs will work for you. The konsole.desktop file is good enough to hang onto, by the way.

Here's one reason why.

Got konqueror?

Type "konqueror man: 2>/dev/null". Try that without the redirect that sends the garbage to the null device for comparison.

That little demo (plus and minus garbage) almost says it all.

Enjoy! (While you still can.)

:-)

You can also look up specific commands and you can use the info docs instead of man if you like.
also works and will often redirect you to the man page if the info files don't exist.

These are beautifully formatted docs, not like the old B&W man docs viewed in VIM with a Chinese Box of commands that you practically have to hit reset to get out of. (That's a former DOS/Win perspective. Forgive me.) ;-)

Half solved. My exec files run and binary executables execute.

http://www.linuxquestions.org/questi...ml#post4585202

That should link to #26 in the thread.

openSUSE tested so far.

Kubuntu may need additional code to enable sandbox installations, but I think it's getting close.

Will pick up or link to the iso problem later. That too is now solved, but not yet posted.