Re: Fwd: /bin/sh linked to dash? SOlVED, however..
The first I did (after having computed successfully with mopac on the
basis of "sh -> bash"), was to remove the symlink, having now again
"sh -> dash", in order to avoid possible problems in addition to the
many I am having since I added GPU to CPU for simulations.
Then I went through the forum of AMBER, into whose metacode mopac is
found. I came across a suggestion alike the one I used.
******************************************
On Wed, Nov 11, 2009 at 5:04 PM, Wallace Kunin <kunin.marshall.edu> wrote:
> This is antechamber.out:
>
> Total number of electrons: 58; net charge: 0
> >
> > Running: /home/kunin/amber10/bin/mopac.sh
> > ln: creating hard link `FOR005': File exists
> > /home/kunin/amber10/bin/mopac.sh: 12: Syntax error: Bad fd number
> > Error: cannot run "/home/kunin/amber10/bin/mopac.sh" of bcc() in charge.c
> > properly, exit
Reply from: Jason Swails <jason.swails.gmail.com>
Date: Wed, 11 Nov 2009 17:30:35 -0500
Hello,
As for confirmation about /bin/sh, I too use Ubuntu. The first thing I did
when I began setting up my environment was to redirect /bin/sh to /bin/bash
rather than /bin/dash, since it causes a lot of headaches. You could, of
course, go through the Amber source tree and change #!/bin/sh to #!/bin/bash
to make it use the proper shell, but this issue is pervasive enough that I
think it is worth changing /bin/sh permanently.
If you google "Bad fd number", you will see countless hits of people saying
"Ubuntu links /bin/sh to dash rather than bash." (since /bin/sh is a
symbolic link to /bin/dash). The almost unanimous fix for this issue is
something along the lines of "sudo rm /bin/sh; sudo ln -s /bin/bash /bin/sh"
to make /bin/sh point to /bin/bash. It would be worth seeing if this fixes
the issue.
Any script that uses #!/bin/csh should be fine since it explicitly calls
cshell as long as you have cshell installed (which Ubuntu does NOT come with
by default, but can be obtained via apt-get install csh). Same with
#!/bin/bash.
Hope this helps,
Jason
************************************
It seems that with "sh -> dash" I should correct some hundreds of
codes in FORTRAN. Luckily, I have abandoned such main code, only using
some fringe tools. In those rare cases I'll put temporarily again the
symlink for "sh -> bash".
Computational chemical code is very conservative. Beyond those
marginal problems above, such conservative aptitude is faced by the
need of following the needs of GPU-CPU computing, which is at the
opposite side of conservative.
Among the many odds I am encountering, at "gnome-session" or
"ck-launch- session gnome-session" I am warned that metacity-session
was not saved. Actually, I am using "twm" not "metacity". Very
confusing.
Both NAMD (a molecular-mechanics code) and VMD (a viewer and tools for
NAMD) use CUDA. Launching VMD as the first application, it says
"creating CUDA device pool and initialing hardware" and works fine.
Closing VMD, if I try to launch it again, the same phrase "creating
CUDA..." appears, while the computer hangs. Same issue if VMD is
launched after a run with NAMD.
With the large files from NAMD (20-100 GB) I need the speed up of CUDA
to VMD for my system of nearly 300,000 atoms. The version on CPUs
alone has difficulty.
In contrast to VMD, NAMD needs to have the CUDA cards ready for use,
which I do with "nvidia-smi -L" command. However, if issued without
gnome support (from the linux prompt, without X-server) NAMD fails to
find the CUDA cards and the computer hangs. From a terminal window in
gnome-2, NAMD runs fine on CUDA, however, once the run is finished, it
proves difficult to go out from gnome/X-server and the computer hangs.
I have tried with "user logout" or even "Ctrl-Alt-F1". Normally the
computer hangs, only rarely it was closed correctly. What is wrong in
my system has defeated so far my understanding. The only good point is
that once a NAMD simulation, or a VMD investigation, are started, they
run without any problem and finish without any warning.
thanks
francesco pietra
On Sat, Jul 2, 2011 at 10:21 PM, Lennart Sorensen
<lsorense@csclub.uwaterloo.ca> wrote:
> On Fri, Jul 01, 2011 at 10:39:05PM +0200, Francesco Pietra wrote:
>> Solved by
>>
>> # mv /bin/sh /bin/sh_original
>>
>> # ln -s /bin/bash /bin/sh
>>
>> now
>>
>> ls -l
>> sh -> /bin/bash
>>
>> and mopac does its job. Hopefully, this should also allow the hundreds
>> of other codes inside the main code to work, if the same problem
>> occurs.
>>
>> However, I would like to have the opinion of "those who know" if this
>> is the correct way of doing and why with wheezy this change.
>
> Yeah as already said, not the thing to do.
>
> Fix the scripts. If they say /bin/sh then they are asking for a posix
> shell, and trying to do anything else is a bug. Trying to use bash
> features is certainly a bug. If the scripts explicitly ask for bash
> then it is fine to use bash features.
>
> --
> Len Sorensen
>
Reply to: