Page 2 of 2 FirstFirst 12
Results 11 to 12 of 12

Thread: define functions/variables to be used in .desktop entries

  1. #11
    Join Date
    Jun 2008

    Default Re: define functions/variables to be used in .desktop entries

    Thanks for the further explanation.

    I must admit that I can not really follow your path of thought from begin to end (I e.g. wonder while the system manager puts something into /etc/profile.local, which is by definition something to be experienced by all users whenever they start a loginshell).

    In any case, As you wonder why we ask you for pertinent, precise and exact information on what you are doing, having and getting, maybe some explanation. I already pointed you to a particular paragraph of . The whole article is worth reading. Not everything there is applicable to the openSUSE forums, but many of the ideas there are. All here are volunteers spending some spare time in trying to help their fellow openSUSE users. But even spare time is not abundant for most. So there is a chance that people choose those threads for helping that offer a nice problem, with a good discussion. Asking for each and every bit of information is not a good discussion for many. It is simply spoiled time. When this was payed support, you would no doubt find that time specified on your bill.

    While we understand that you suppress e.g. passwords and the like from being published here open on the internet, you must weigh off the amount of information you want to provide against the willingness of the people to help you. More paranoia: less help. People do not like it to provide help based on assumptions and the conclusions an OP may have jumped to based on not shown computer facts. In short: often people here will not believe you, they will believe the computer (and they trust you in showing what the computer showed you, unabridged, unaltered, except when you explicit and very clear tell what you left out).


    Let we go more technical.

    The following may be (partly) known by you. In any case some people above (including me) got the idea that you then do not fully understand the consequences while designing the solution to your goal.

    A process is a running instance of a program. Each process has, apart from the memory it uses for code and data, a piece of memory call "process environment". Amongst other things, there can be named environment variables with their value in the process environment. A process may start a new process, a child. The environment of the child is enherited from the parent. Thus environment variables and their value are forwarded from parent process to child process, but never the other way.

    Very short without much details.

    bash is a program interpreter and in Unix/Linux those programs are called scripts. A bash script uses (like every programming language) variables which can have values. For many there is a confused relation between the variables used in the script and the process variables that belong to the bash process that runs the script. That confusion derives from the fact that one most often see no difference in setting the value of such a variable, nor in using it. Example
    echo $AAP
    gives no clue if AAP is only inside the script or also known in the environment. But it is possible to e.g. move a variable from the running script to the environment: the export command.
    export AAP
    will put AAP in the process environment (with it's value noot) and thus will not only be available to the running script, but also to child processes started by a command in the script that follows. E.g. assuming that mies is a executable (found using PATH) when now calling
    mies wim
    the program mies will be able to use the environment variable AAP getting the value noot.

    An alias is to create a new command, often as a shortcut to another command. Some of the aliases provided by default:
    alias beep='echo -en "\007"'
    and for those with MS-DOS traumas:
    dir='ls -l'
    The bash man page explains very clear when alias are interpreted by the shell (on "simple commands") and if one can use aliases of aliases.
    There is a convention that a user can add aliases for her/his convenience by putting them in ~/.alias. This is because ~/.bashrc has the line:
    test -s ~/.alias && . ~/.alias || true
    In other words personal aliases are added when ~/.bashrc is sourced.

    A function is something different. It is a typical feature of a programming language. It is a form of re-use of code. They can be very large. They can apparently also be exported to the environment and thus available to child processes. But that is only useful if the child process runs a script of the same language (bash script)

    I see no relation between aliases and functions and certainly not that the one is going to replace the other.

    Further read from the bash man page you could do is about INVOCATION, which will tell you about login shell (or not) and interactive shell (or not).

    And remind that your executable program in /my/private/path/ will only be interpreted by bash because of the shebang #!/bin/bash

    Henk van Velden

  2. #12

    Default Re: define functions/variables to be used in .desktop entries

    I found the text about replacing aliases by functions in man bash, at the end of paragraph ALIASES, 'For almost every purpose, aliases are superseded by shell functions.'
    I guess it is meant to explain, not to announce that aliases will deprecate.
    Thanks, Henk.

Page 2 of 2 FirstFirst 12

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts