set and export using bash script
 

Hi,

command and bash script stuff
----

PATH=$PATH:/home/al/bin
export PATH

Those ^^, when each line entered as separate command (two commands entered) it works very fine, appends onto the $PATH as I would expect.

But the next 3 line bash script must need quotes somewhere or perhaps something simple that is missing since it doesn't yet work:

#!/bin/bash
PATH=$PATH:/home/al/bin
export PATH

does it need quotes thus?: export "PATH"

how about?: PATH="$PATH:/home/al/bin"

Thanks. Alan.

did you make it executable?
eg. chmod +x file.sh

I'm not sure but it sounds like a subshell problem. For that shell/script it should be fine, but it doesn't propagate 'upwards', so to speak. So when that subshell running the script exits, it takes its environment (including path) with it. You can run it as
and that may work for you.

Yes, executable:

bs104:~/bin # ls -la
total 9
drwxr-xr-x 2 root root 104 Jan 2 23:53 .
drwx------ 15 root root 480 Jan 2 23:53 ..
-rwxr--r-- 1 root root 99 Jan 2 23:53 script


#!/bin/bash
echo To enact it, must enter: \(dot_space_script\). script
export PATH="$PATH":/home/al/bin

The dot_space_script method reported by digiot works.

See my cheat sheet. (The echo line) reminds me. And gpm (mouse copy/paste) the . script from the echoed line then strike enter key

That's working for now anyways.

I thought the export made it global rather than be a child shell. Evidently not.

Alan.

I wonder, how could I bring up a sub shell that is with the append onto the PATH -> then interactively enter another command (using cdrecord to burn cd is what I'm doing) then when the cdburn is done, the shell could exit.

In that way, the PATH would return to its former state.

Thanks. Alan.

I guess you would have to write it like :

export PATH=$PATH:/home/al/bin

or

PATH=$PATH:/home/al/bin
export $PATH

I'm not sure I understood the question. If you want the script to be interactive, you could do something like
which should give
But if you want a script for CD burning, there's this thing at freshmeat called bashburn you might like. I haven't really used it, but it looked cool. :)

Thanks. Not the script interactive. But, like this:

Rather than

which effectively appends onto PATH at the *Parent* level.

Instead, as you earlier reported I had affected a child shell (or spawn a child something or other) that then went away once the command had completed then relegating back to the Parent shell but now also without any longer the appended PATH

How do I retain the child shell so can enter command number two into it (command number two enters after the PATH had been appended onto).

It is the child shell or the spawned child whaterver it's called that I meant (enter a 2nd command onto it) rather than interactivity via the script prompting the user for input.
--

I need to learn some sudo stuff too. Some if not all of what I'm doing should able do with sudo.

Can anyone refer me to good sudo/visudo helps, tutorial?
--

I,m running cdrecordeasy which is a Perl script (dl from the www)

cdrecordeasy file.iso

merely runs cdrecord with the needed parameters that I had set in the config at the top of the Perl script.

Must currently su to root then run since I not yet change permissions so user can run.
--

I'm the only user. I got lots executable scripts in /home/user_me/bin

Often times when I'm root doing something, I'd like to run one of those user_me/bin scripts. But /home/user_me/bin is not in the root PATH

Thus I thought to try as root append /home/user_me/bin to root PATH rather than copy all the scripts to a second location in the root PATH

Alan.

Huh. I'm getting kind of confused. :) I'm going to take the points in reverse order.

As far as /home/user_me/bin, you can add that to root's path in /root/.bash_profile or /root/.bashrc if you wish.

As far as burning CDs as normal user, I'd just change the perms or do whatever's necessary. An admin should certainly be able to *lock down* the removable drives but, IMO, it's plain stupid to have it that way by default and make 99% of users change it. A little bit too Unix-y for my taste. So, like I say, I'd go ahead and enable that.

As far as sudo, a google search looks like some useful stuff.

As far as the first bit, I think I partly see what you want, though I'm not sure why. First script had the path getting lost, which wasn't what you wanted. Second script works but affects your current shell's path, which also isn't what you want. But this isn't something interactive. Okay - so why can't you add additional commands to the script that's running in the subshell?

#!/bin/bash
commands
PATH change
commands
exit

The second set of commands should still be working.

-- But actually, why not just have the path permanently changed? I mean, if you need something on your path, put it on your path. Or write wrappers to it. Like I have ~/sbin which, in my case, means a 'script bin' instead of 'system binaries' and it's on my path. I also have a ~/bin where I put some compiled executables and any that are in subdirectories of that, I just symlink or write wrappers to in ~/bin itself. Point being that, if I need something on my path, I either put it on my path or put my path on it. ;)

Case of the obvious overlooked by me. That but then echo/prompt then read in the second command is something likely would work (otherwise would need to edit the hard coding each time prior to running).

But I agree with you about the other ways you mentioned and they're being of higher practicality.

I've just not enough experience yet with multiplicity of ways available versus to make a good choice.

Thanks much! Now I'll have to document what I do so I can remember it the next time around.

By wrapper, do you mean a script in another folder that acts as an init script which refers/launches script number two (number two resides in a folder that is not in the path) hence a method to get number two launched.

sym links I can do. They're easy. must be root though. next is *just* a for instance.

al@bs104:/usr/bin> pwd
/usr/bin
al@bs104:/usr/bin> ln -s /usr/local/bin/perl perl

In that way, i can leave shebang lines as

#!/usr/bin/perl

when the perl I want it to use is in /usr/local/bin

Thanks. Alan.

That's the big downside to Linux's extremely configurable, adaptable approach - there's usually at least two dozen ways to do something and a dozen of those are good ways. I don't have enough experience myself to often make a good choice and I suspect even veteran gurus sometimes make suboptimal choices, too.

Mm, not necessarily. It can be a script chain (like mozilla's way of starting itself which is, frankly, a mess and to which I do indeed add yet another script) or it can just be a small one or two liner to invoke an executable. Like I was playing with anti-aliasing my gtk1 apps (which isn't really worthwhile) and wrote things like
and saved it as emelfm and, since ~/bin and ~/sbin take priority on my path, I could run that version without changing anything else, such as the binary name or the entry in my wm menu.