Hello EveryBody...

I am stuck at a issue in shell scripting, which is driving me crazy.

I had tried all the possible ways,yet unable to reach a solutions..So, here looking for scripting monks to solve my problem,please help me out..

Situation is something like this..

I am working on a application,which runs on C shell. For this i had created a installation script, which installs my application in the system, it is working fine. Now, the problematic part is that I had set an alias in ".cshrc" file, which invokes my application when any user types it. But for an alias to take effect, I need to re-login into the system,because I have to read ".cshrc" file again, in order to take effect of my alias.
However I can use "source ~/.cshrc" file after my installation, so that my aliasing works without logging back again. But Requirement is that,just after installing the application,alias should be available to user,without logging back again and without issuing any extra command.

I had tried one other way is that, i had created a symbolic link in ~/bin directory, which points to my application to be run, but even that require, to issue rehash command in order to modify internal command hash table.

So, my overall problem is that changing alias in subshell should be reflected to parent shell,without running any other command(all commands should be run in installation script only).
Or, in other way how to rehash parent shell from subshell.

The ultimate requirement is that,the command that will run my application,should be available just after executing the installation script,either by aliasing or by rehashing,or by any other means...


Please Help me out....I am finding me helpless at this point..

Thanks in Advance...

AJEET KUMAR GUPTA

Typically the way this is handled is by adding whatever changes you need to the original file then source the original file.

IDK any way to create a new alias in the parent shell by running a program in a subshell so you're going to have to do something in the first shell -- like "source"ing or "exec"ing your installation utility. "source"ing is not an option if the installer user's shell is not the same as your installation utility and "exec"ing is messy because your installation utility has no way to know what to exec back to put the installer user back where they started.

Surprising that this didn't work: "I had tried one other way is that, i had created a symbolic link in ~/bin directory, which points to my application to be run, but even that require, to issue rehash command in order to modify internal command hash table." What are the symptoms?

@rweaver: The source ~/.cshrc is not working from shell script, Even if by any means I get able to do this, then that changes is reflected in Subshell only, Please Give any other solution, or any other way of doing this..

@catkin: Thanks catkin,for having a deep look on my question.

Yes, That ~/bin option does not work, How ever that is working on any Bash shell,which automatically search for any command in ~/bin, but in csh, simply putting my command in ~/bin,does not work,I need to issue rehash command, in order to let OS know,that i had added some more command and please update your hash table,Only by issuing "rehash", that command is available for execution.

So,Please provide any solution,that do the same..

I guess you don't want "Stop using csh and start using bash" although there are many god [ <== great typo, had to leave it in ] reasons for doing so.

IDK csh but could you change the command line that the installing user has to use to run your installation utility such that it does issue a rehash command? In bash something like this would workAny writing to the terminal could be changed within installation_script.sh to write directly to /dev/tty rather than stdout withIt is a scary technique because the installing user's shell is going to try and execute any old garbage that does get through to stdout but you have got yourself an intractable problem and desperate measures are needed to solve it!

Actually the sane thing is to change the specification.

1 members found this post helpful.

@catkin:
I know that this all things gonna work fine,if the environment is "BASH", but requirement is something like that, forcing me to work in csh..

There is one question, is it possible to replace parent shell by subshell, such that alias that i had set in my subshell,will be available for user. That means the shell from which user executes the installation script will be replaced by another shell,which will be invoked from subshell, and this newly created subshell contains my alias.
if it is at all possible then, what will be the value of "$SHLVL" in newly created subshell...?

Try it! As mentioned above, if the installing user would exec your installation script, then your installation script could exec a new login shell and you could script its process environment to be similar to the original one by snapshotting the process environment (envars, umask, open file descriptors ...) at the beginning and restoring it at the end. Anything set by the shell initialisation files -- including your all-important alias -- would be set, possibly changing several things about the shell environment from the user's perspective -- a Bad Thing.

Personally I'd strongly recommend that whoever agreed to the specifications should be subject to technical review before they promise to deliver the impossible (or, at best, the very messy) again. Do the end users actually care? They may be quite amenable to logging off and back on after installation. Hey, on Windows systems many installations require a reboot!

@catkin:

Right, I am agree with you, better and cleaner way is to go via re-login.
But, one question i am thinking is that,how the standard installation files that comes in linux,make the command available after "make install" command. sya, I had a "Net-Snmp" tar ball, and i go through installation procedure, and after installing commands are available for execution(It happens in BASH, I am not sure about csh). So, How they do the things? isn't their any replacement??

I guess bash is smarter about updating its hash when new files appear in the $PATH directories. Only "guess" because it has always "just worked" so there's never been any reason to study it.

It is surprising that csh is not being more helpful on your systems. It might be worth starting another thread, specifically about csh's hash and adding executables in the $PATH directories.

1 members found this post helpful.