Announcement

Collapse
No announcement yet.

Shell Can Run On Our Desktop (the scrood shell utility).

Collapse
This topic is closed.
X
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    Shell Can Run On Our Desktop (the scrood shell utility).

    Shell Can Run On Our Desktop (the scrood shell utility).

    WARNING: EXPERIMENTAL. If you set your mime-types to use this as the default application to open executable files with, I don't know how well, you can revert. I'd copy all the "shared" stuff in your ~/.kde folder to "shared-bak" so you can brute-force a reversion, unless you enjoy living dangerously.

    Here's why I wrote this:

    I think the wrappers or shell plugins for dolphin and konqueror are wiping out too much of the environment. At least in version 12.x that seems to be the case. And this may not seem like a big deal to most folks, but like the missing defs for pthread_create, sem_wait, etc., this DOES affect those of us who do low level coding (like C/C++ or assembler).

    This is the 'scrood' shell program to get konqueror and dolphin back to where they should be, able to run sandbox programs using your own path and LD_LIBRARY_PATH definitions. In this, I have defined these vars in my .profile file, which only loads once. I'd like it to be in my .bashrc file so it can be switched on and off depending on which versions of the libs I want to run, and that worked for a while but it seems to have quit by the time I rebooted.

    Whatever. :-)

    The following is the version I now use.

    Binary programs won't run automatically when you click on them and the ENTER key will not launch them (elf compiled binaries) either, but if you right click on one the top menu item will be "scrood" which will launch them fairly easily (at least no 'terminal' and no typing.

    Shell scripts will just run... like they always did, headless and having no idea where they were launched from in most cases.

    Still gettin' to the part about why this stuff is so important and why you'll see that the problems with brainless scripts running by accident are not as important as being able to run script programs with cursor keys and the ENTER key.

    Or do you want to have to write a GUI app for single little thing? :-)

    Or do you enjoy dropping down to a terminal and typing the name of a program every time you need to run one that's not in your menus?

    Well. Not me.

    Nuff said?

    Here we go. The SCROOD shell plugin fixer for your file manager.
    Code:
    #!/bin/bash
    # Allows konqueror and dolphin to run executable programs 
    # like in the old days.
    
    #This is where LD_LIBRARY_PATH is defined
    SCROOD_DEFS=.profile
    
    # parse, reload and re-export selected parts of .bashrc or .profile
    # Here's LD_LIBRARY_PATH for sandboxed shared libs.
    scrood=`echo "$(<$HOME/$SCROOD_DEFS)" | sed '/LD_LIBRARY_PATH/!d; s/export LD_LIBRARY_PATH=//; s|:\$LD_LIBRARY_PATH||'`
    export LD_LIBRARY_PATH=$scrood
    
    #test function disable when no longer needed.
    kdialog --msgbox "Running: $1 .
    with libs = $LD_LIBRARY_PATH .
    and PATH = $PATH .
    Remove this from your SCROOD shell utility after test and .
    optionally \"open with\" scrood as a default to run your .
    executables.
    "
    
    # This is all it needs unless you are in a sandbox installation
    $1 # run the program
    See the two lines above.

    Let's hope those changes were for a "security" issue. (And I don't think it was.)

    But some of the changes in the "mondern linuxes" are only likely to make the next generation of developers have a harder time getting started.

    I love the alt-ctrl-F# keys in this kde, for sure, tho. We can recover from an accidental switch to a desktop that hasn't been logged on.

    That is VERY nice! I use it frequently. ;-)

    .

    #2
    Re: Shell Can Run On Our Desktop (the scrood shell utility).

    Woops. One more quick note about 'reverting', should you find yourself in a jam.

    Last time I checked, KDE keeps the current configs in the /var folders somewhere while you are running and then saves them back when you log out. As a result, many of the changes you may make manually to your .kde/shared/config files will get overwritten when you log out.

    So you will have to hit 'reset' after reverting (moving 'shared-bak' back to 'shared') or you'll need to make the move from a terminal login and then probably reboot... or if you have a second desktop with access to the first, that would work too. But the KDE that runs that desktop you are modifying cannot be allowed to mess the changes though or you'll very likely end up right back where you were.

    Other than that... I done this many time, and have even saved entire home folders through install cycles, including the configs by just renaming them, so the danger here is fairly minimal, even if it messes with your defaults; namely the application to open an executable with.

    And that is usually not set at all, from what I've seen in the Live CD and the DVD. (That's v. 11.10 and 12.4)

    But then who knows what craziness you've done to YOUR setup. :-)

    Comment


      #3
      Re: Shell Can Run On Our Desktop (the scrood shell utility).

      One day it works, the next day it causes konqueror to quit painting itself.

      scrood Revision 1 (needs duplicate definitions of custom paths in both .profile (gui apps) and in .bashrc (terminal apps). See previous post for the different issues involved for terminal v. gui apps.

      I am now loading the defs from .bashrc again. And that's fine because 'make' apparently already needs 'bash' anyway. (This IS a programming helper, among other things.)

      However, I've been forced to define my PATH and my LD_LIBRARY_PATH in both .profile and .bashrc in order to get things working again in both terminal and gui contexts for both user and superuser.

      :-(

      Again, I guess... no guarantees. But today it works and that's what I need for today.

      Code:
      #!/bin/bash
      # version 1.1
      # Allows konqueror and dolphin to run executable programs 
      # like in the old days.
      
      #This is where LD_LIBRARY_PATH is defined
      SCROOD_DEFS=.bashrc
      
      # parse, reload and re-export selected parts of .bashrc or .profile
      # Here's LD_LIBRARY_PATH for sandboxed shared libs.
      scrood=`echo "$(<$HOME/$SCROOD_DEFS)" | sed '/LD_LIBRARY_PATH/!d; s/export LD_LIBRARY_PATH=//; s|:\$LD_LIBRARY_PATH||'`
      export LD_LIBRARY_PATH=$scrood
      
      # This is all it needs unless you are a programmer.
      nohup $1 & # run the program
      return 0
      Any ideas? The simpler the better. Where can we put this or some other code to assure that both the PATH and the LD_LIBRARY_PATH are present in the context of both terminal and gui apps so linux behaves like it's integrated from the bottom (terminal) to the top (gui).

      Comment

      Working...
      X