SourceForge has been redesigned. Learn more.
Close

#349 Shell unusable on 2+ Boxes

release
closed-fixed
Program (402)
7
2006-01-02
2004-01-20
No

I have NEdits on box1 and box2 displaying on box3. The
Bourne Shell is installed at /bin/sh on box1, /usr/bin/sh
on box2. Since the shell pref is saved on the server, it is
impossible to use shell actions on both instances of
NEdit.

(I felt this bug crawling for some time; finally it bit me.)

Discussion

  • Tony Balinski

    Tony Balinski - 2004-01-20

    Logged In: YES
    user_id=618141

    Can't you (in extremis) change the resource on the command line?
    eg
    nedit -xrm 'nedit.shell: /bin/sh' ...other-parameters...

    This would solve your problems on a one-off basis.
    Alternatively you could set up your own resource file for
    nedit to look at. See

    http://www.nr.no/~joachim/Niki/index.php/NeditFaq/customize

     
  • Thorsten Haude

    Thorsten Haude - 2004-01-20

    Logged In: YES
    user_id=119143

    The problem could be solved, but the bug remains. It may not
    always be possible to get root permissions.

     
  • Nathan Gray

    Nathan Gray - 2004-07-09
    • priority: 7 --> 2
     
  • Nathan Gray

    Nathan Gray - 2004-07-09

    Logged In: YES
    user_id=121553

    Not going to be fixed before 5.5.

    I don't understand, what do root permissions have to do with it? As Tony
    pointed out, you can override this from the command line. Also, I think
    you can use the XENVIRONMENT env var to set resources on a per-host
    basis.

     
  • Thorsten Haude

    Thorsten Haude - 2004-07-09

    Logged In: YES
    user_id=119143

    I see more than one way to circumvent this bug.
    Nevertheless, client-dependent settings should not be kept
    on a single location at the server. It's awkward even if you
    don't use the NEdits on box1 and box2 at the same time.

    This along with the dreaded csh-issue make an important
    chunk of NEdit's functionality unusable for some users. X
    resources are meant to offer customizability, not to provide
    basic functionality.

    Root permissions could be used to symlink the shell's location.

    Could you please not change bug priorities? I doubt that
    they are meant to be juggled around while doing a release,
    esp. since some people want to release much more often than
    currently done. This is a bug that could possibly cripple
    NEdit for less experienced users, and thus should have a
    high priority.

    A simple list should be sufficient to remember which bugs
    should be fixed before the release.

     
  • Thorsten Haude

    Thorsten Haude - 2004-07-09
    • priority: 2 --> 7
     
  • Nathan Gray

    Nathan Gray - 2004-07-10

    Logged In: YES
    user_id=121553

    Other issues aside, what kind of screwed up system doesn't have sh in /
    bin? The shell menu in NEdit is going to be the least of your problems
    --- a massive number of shell scripts in the world start with:
    #!/bin/sh

    File a bug with your distro, or whomever set up that box.

     
  • Thorsten Haude

    Thorsten Haude - 2004-07-13

    Logged In: YES
    user_id=119143

    Yeah right, we jump through loops to circumvent Motif's
    idiosyncrasies but we keep client resources on the server
    because righteous systems shouldn't be affected.

    What if you want to use csh on one box and ksh on the other?

     
  • Robert Goddard

    Robert Goddard - 2004-11-18

    Logged In: YES
    user_id=1161813

    This is important! As a general rule, X resources should NOT
    be used for properties that refer to a particular host --
    especially filenames. The following should be Preferences,
    not X Resources:
    tagFile
    shell
    printCommand (and other print options)
    serverCommand (and other nc options)

     
  • Eddy De Greef

    Eddy De Greef - 2004-11-23

    Logged In: YES
    user_id=73597

    With the current preferences implementation, I'm afraid that
    would solve nothing for people working on different hosts
    sharing the filesystem through nfs. All NEdit instances
    would read the same preferences file (which uses the
    X-resource mechanism, BTW). In fact, that would even be
    unacceptable, because if you log in locally on one platform,
    you don't want the settings of another platform, stored in
    your shared preferences file.

    For this to work, the preferences mechanism needs to be
    extended: it should be possible to load/save
    platform-specific resource files, but it will be up to the
    user to specify the platform, most likely through some
    environment variable, eg. NEDIT_PLATFORM (you can't expect
    NEdit to automatically guess what you mean by platform,
    given the huge number of platforms NEdit runs on).
    We could then organize the preferences as follows:

    .nedit/nedit.rc -> platform-independent stuff.
    .nedit/platforms/default.rc -> default platform-dependent
    stuff
    .nedit/platforms/HPUX.rc -> NEDIT_PLATFORM == HPUX
    .nedit/platforms/LINUX.rc -> NEDIT_PLATFORM == LINUX

    The default settings would be loaded and saved when
    NEDIT_PLATFORM is not set.

     
  • Thorsten Haude

    Thorsten Haude - 2004-11-23

    Logged In: YES
    user_id=119143

    I think this is a different issue. If I choose to use the
    same $HOME on different boxes (or my admin chooses for me) I
    have to live with the consequences. (Though it would be nice
    to find a way around this.)

    The NEDIT_PLATFORM solution looks like overkill to me. We
    don't need to differentiate between all platforms NEdit runs
    on but only the one actually in use at a given site. If the
    admin uses a single $HOME for his users AND configures
    platforms with identical `uname` in vastly different ways he
    deserves what's coming.

    IMHO the complete solution for this would be to allow access
    to all settings from macros and to allow multiple settings
    location. Then get NEDIT_PLATFORM in a macro and -import any
    platform specific stuff. See SettingsSystem on Niki for some
    thoughts on this.

    The original problem is that client resources are saved on
    the server. This is contrary to the idea that X11 apps
    should be network-agnostic. A given NEdit using a given
    nedit.rc should behave the same no matter where it displays.
    (With the possible exclusion of display-related settings,
    which is not the case here.)

     
  • Eddy De Greef

    Eddy De Greef - 2004-11-23

    Logged In: YES
    user_id=73597

    Maybe it is a different issue, but it cannot be decoupled.
    If you want to work with platform-specific settings, whether
    you store them as regular resources or as preferences, you
    need such a mechanism.

    I didn't mean that NEdit should maintain platform specific
    settings for every possible platform it could run on. As I
    wrote, it is up to the user to define what a platform is.
    NEdit would only use NEDIT_PLATFORM for the name of the file
    in which the platform specific preferences are stored. If
    you set NEDIT_PLATFORM to the day of the week, you can use a
    different setting every day of the week. The user
    differentiates as much or a little as (s)he wishes.

    How you implement this, with a simple extension to the
    preferences mechanism as I suggested, or with some fancy
    plugin mechanism that allows you to pull preferences from
    the other side of the galaxy, doesn't matter.

    A solution requiring macros is not a complete solution: do
    you really want to force someone to learn macros just to set
    the print command?
    In the scheme that I suggested, all the user needs to do is
    to set an additional environment variable and all the rest
    can be done via the regular GUI (provided that we add those
    preferences).

    If you think that's an overkill, I suggest you close this
    bug. There are various ways of overloading client-specific
    X-resources, as others suggested. You don't need macros for
    that.

     
  • Thorsten Haude

    Thorsten Haude - 2004-11-23

    Logged In: YES
    user_id=119143

    I don't think that the two issues are coupled. There is a
    bunch of stuff handled exactly the way the shell should be
    handled. (Actually too much, eg. the default size could
    possibly be display-dependent.) So simply put nedit.shell in
    nedit.rc. This file very often *is* on the platform in
    question. If it is not, the user or admin can patch
    something together with NEDIT_HOME. Yes, that would have
    some drawbacks, but that's what you get for mounting $HOME
    on systems not even having the same shells installed. (I
    wonder how shell startup files would be handled.)

    Setting the server's (!) resources with command line options
    to take care of different client configurations is no
    solution, it's a workaround. Again, except for display stuff
    NEdit's behaviour should not differ displaying on different
    servers. It's no solution either: As soon as you run a
    second NEdit on the same server from another box, the shell
    (and print) settings are wrong for one of them.

    Let's have another look at the situation you describe:
    Vastly different environments sharing the same $HOME. To use
    different shells with the current settings system, you would
    *still* have to use resources, so there is nothing gained by
    keeping it.

    A third groups are users who access the same client through
    changing servers and are forced to install their settings at
    each of them.

    So, in conclusion, there is a large number of users who
    would profit from the change I ask for, namely all those
    running NEdit from different boxes on the same display.
    There is nobody worse off, since pathologically multi-$HOMEd
    users are already required to take care for themselves.

    (And I really wonder why I have to defend the statement that
    client resources should be on the client.)

     
  • Eddy De Greef

    Eddy De Greef - 2004-11-23

    Logged In: YES
    user_id=73597

    Ok, I get your point. I agree for the shell resource, and
    probably most others. But for the print command, it's a
    different story: we already have a crude
    platform-differentiating mechanism (at compile time). If you
    put the print command in nedit.rc (because it's a client
    resource), you essentially short the differentiating
    mechanism: the value stored in nedit.rc will shine through
    on all platforms. Then you force users to use additional
    resources, whereas the original defaults may have been
    satisfactory.

     
  • Thorsten Haude

    Thorsten Haude - 2004-11-23

    Logged In: YES
    user_id=119143

    Printing was only an afterthought, I think I did a single
    printout with NEdit since I started using it. I don't really
    have an opinion on that.

     
  • Nobody/Anonymous

    Logged In: NO

    To get back to the original problem, the answer is simple:
    instead of using execl() in shell.c, use execlp() to run the
    shell. Then change the default shell from "/bin/csh" to
    "csh". If csh is not in the path *somewhere*, you can change
    your .cshrc, .profile, .bashrc or other. If you still want
    an absolute path, you can set one.

    I don't know why execlp() isn't used already. Is it missing
    on some unix systems?

    Tony

    PS As for the platform specific $NEDIT_HOMEs, use the
    environment. That's the point of it, after all. I can see
    loads of people say "I wrote a wonderful macro, but it's not
    there anymore!" Why? Because it was written and saved on a
    different system. At the shell level, you can always do

    setenv NEDIT_HOME "$HOME/.nedit/`uname`"
    if ( ! -d $NEDIT_HOME ) mkdir -p $NEDIT_HOME

    in your .cshrc/.login/.profile/.bashrc... Says it all
    really. I do something similar for managing light versus
    dark nedit backgrounds and syntax highlighting style sets.

     
  • Nobody/Anonymous

    Logged In: NO

    I forgot: for non-nedit.rc parameters, you can use a
    $XUSERAPPLRESDIR env variable (as far as I remember) with
    various cryptic % sequences for all kinds of things. Put a
    NEdit resource file in a corresponding file, and you're
    done. OK, not for newbies, but certainly possible for sysadmins.
    Tony

     
  • Thorsten Haude

    Thorsten Haude - 2004-11-24

    Logged In: YES
    user_id=119143

    I don't think that using $PATH or $XUSERAPPLRESDIR would be
    the solution. You still wouldn't cover different shells or
    different absolute pathes.

    Why would you change your startup file if csh is not in $PATH?

     
  • Thorsten Haude

    Thorsten Haude - 2006-01-01
    • assigned_to: nobody --> yooden
     
  • Thorsten Haude

    Thorsten Haude - 2006-01-02
    • status: open --> closed-fixed
     

Log in to post a comment.