Linux - GeneralThis Linux forum is for general Linux questions and discussion.
If it is Linux Related and doesn't seem to fit in any other forum then this is the place.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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
Originally posted by digiot So when that subshell running the script exits, it takes its environment (including path) with it.
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. Not the script interactive. But, like this:
Rather than
Code:
. script
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
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.
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
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.
Originally posted by acummings I've just not enough experience yet with multiplicity of ways available versus to make a good choice.
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.
Quote:
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.
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.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.