Re: Fwd: /bin/sh linked to dash? SOlVED, however..
On Sat, Jul 02, 2011 at 11:34:30PM +0200, Francesco Pietra wrote:
> 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.
Well they are wrong. /bin/sh is and always has been posix shell, not
bash (except on many linux systems). Any script that breaks if /bin/sh
is not bash is simply broken and should be fixed.
> 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.
Just because lots of people say "This works" doesn't make it right.
> 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".
Finding all scripts with /bin/sh and changing them to /bin/bash can be
done in a couple of lines of perl. Trivial to do really, and fixing the
problem once and for all would be a good idea (and /bin/sh is not going
back to bash, it is going to dash or other smaller and more efficient
posix shell choices since it speeds up boot time to not have to load
bash for things that don't require bash). Debian has spent years clearing
out all the bashisms from init scripts in order to allow the transition
to dash.
> 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.
Being conservative is fine. Being wrong isn't.
> 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.
--
Len SOrensen
Reply to: