Bad fd number syntax error

I need some help in running this code. I took this code from (http://easybioinfo.free.fr/?q=content/amber-trajectory-gromacs-xtc-conversion).
I am trying to convert amber trajectory to gromacs trajectory.

When I execute this code, I get some errors. I paste the errors below this code:

    #!/usr/bin/python

#Workflow based on Trajectory Converter - v1.5 by: Justin Lemkul 
#completely reimplemented and improved by Peter Schmidtke & Jesus Seco

import sys,os,re,fnmatch

if len(sys.argv)>4 :
    f=sys.argv[1]
    if not os.path.exists(f):
        sys.exit(" ERROR : Something you provided does not exist. Breaking up.nnUSAGE : python trajconv_peter.py  amberCrd amberTop trajDir trajPattern outPutPrefixnn 
Example : python amber2xtc.py mdcrd.crd mdcrd.top md *.x.gz md_gromacsn")
else :
    sys.exit(" n  USAGE : python amber2xtc.py AMBERCRD AMBERTOP TRAJDIR TRAJPATTERN OUTPUTPREFIXn
    Example : python amber2xtc.py mdcrd.crd mdcrd.top md *.x.gz md_gromacsn
    Note that the AmberCrd can also be a PDB file.n")

crd=sys.argv[1]
top=sys.argv[2]
trajdir=sys.argv[3]
pattern=sys.argv[4]
outputPref=sys.argv[5]

traj_files=fnmatch.filter(os.listdir(trajdir),pattern) #get the fpocket output folders


RE_DIGIT = re.compile(r'(d+)')     #set a pattern to find digits
ALPHANUM_KEY = lambda s: [int(g) if g.isdigit() else g for g in RE_DIGIT.split(s)]      #create on the fly function (lambda)    to return numbers in filename strings
traj_files.sort(key=ALPHANUM_KEY)      #sort by these numbers in filenames

print "Will convert the following files : "
print traj_files

csn=1
for file in traj_files :
    ptrajtmp=open("ptraj_tmp.ptr","w")
    print "currently converting "+file
    ptrajtmp.write("trajin "+trajdir+os.sep+file+"n")
    ptrajtmp.write("reference "+crd+"n")
    ptrajtmp.write("center ~:WAT,CIO mass originn")
    ptrajtmp.write("image origin center :* byres familiarn")

    ptrajtmp.write("trajout pdb_tmp/mdcrd.pdb pdb")
    ptrajtmp.close()
    if not os.path.exists("pdb_tmp"):
        os.mkdir("pdb_tmp")

    os.system("ptraj "+top +" ptraj_tmp.ptr >/dev/null 2>&1")
    if not os.path.exists("xtc_tmp"):
        os.mkdir("xtc_tmp")
    #move to *.pdb
    os.system("cd pdb_tmp; ls *.pdb.* | cut -f3 -d"." | awk '{print "mv mdcrd.pdb."$0" mdcrd_"$0".pdb" }' | sh ; cd ../")   
    pdb_files=fnmatch.filter(os.listdir("pdb_tmp"),"*.pdb")
    pdb_files.sort(key=ALPHANUM_KEY)      #sort by these numbers in filenames   
    if csn==1:
        os.system("editconf -f pdb_tmp/mdcrd_1.pdb -o "+outputPref+"_t1_top.gro >/dev/null 2>&1")

    for pdb in pdb_files:
        os.system("echo "0" | trjconv -s pdb_tmp/"+pdb+" -f pdb_tmp/"+pdb+" -o xtc_tmp/traj_"+str(csn)+".pdb.xtc -t0 "+str(csn)+" >/dev/null 2>&1")
        csn+=1
    if os.path.exists(outputPref+"_traj.xtc"):
        os.system("trjcat -f "+outputPref+"_traj.xtc xtc_tmp/*.pdb.xtc -o "+outputPref+"_traj.xtc >& trajcat.log")
    else :
        os.system("trjcat -f xtc_tmp/*.pdb.xtc -o "+outputPref+"_traj.xtc >& trajcat.log")
    os.system("rm -rf pdb_tmp/*.pdb")

    os.system("rm -rf xtc_tmp/*.xtc")


os.remove("ptraj_tmp.ptr")
os.system("rmdir pdb_tmp")
os.system("rmdir xtc_tmp")

The error is as below:

 vijay@glycosim:~/Simulation-Folder-Feb2013/chapter5-thermo-paper2-Vj/analysis-malto-/28-difusion-coeff-malto-thermo/convert-gromacs-format$ python2.7 amber2xtc.py malto-THERMO.crd malto-THERMO.top TRAJDIR malto*.traj md_gromacss
 Will convert the following files : 
 ['malto-thermo.set11.traj', 'malto-thermo.set12.traj', 'malto-thermo.set13.traj', 'malto-thermo.set14.traj', 'malto-thermo.set15.traj']
 currently converting malto-thermo.set11.traj
 ls: cannot access *.pdb.*: No such file or directory
 sh: Syntax error: Bad fd number
 currently converting malto-thermo.set12.traj
 ls: cannot access *.pdb.*: No such file or directory
 sh: Syntax error: Bad fd number
 currently converting malto-thermo.set13.traj
 ls: cannot access *.pdb.*: No such file or directory
 sh: Syntax error: Bad fd number
 currently converting malto-thermo.set14.traj
 ls: cannot access *.pdb.*: No such file or directory
 sh: Syntax error: Bad fd number
 currently converting malto-thermo.set15.traj
 ls: cannot access *.pdb.*: No such file or directory
 sh: Syntax error: Bad fd number
 vijay@glycosim:~/Simulation-Folder-Feb2013/chapter5-thermo-paper2-Vj/analysis-malto-/28-difusion-coeff-malto-thermo/convert-gromacs-format$

For information, I am using Ubuntu 11.10 (64 bit).

How this error can be corrected? Appreciate any help.
Thank you.

Thread: Software Install Problem: Bad fd number

Thread Tools

Display

Software Install Problem: Bad fd number

I am trying to install some cosmic ray shower software from http://nuclear.llnl.gov/simulation/ and I am having problems.

In particular, I am trying to install v1.5 of CRY (Cosmic-ray Shower Library). The instructions given in the install guide are relatively simple, yet my install fails from the very first «make». The instructions specify to head to the top-level directory and simply type make. The readout I get in the terminal is as follows:

Additionally, I then get a setup txt file in the top-directory that reads:

I have tried many of the standard error correcting measures here that I have read about, but still can’t fix this problem. I have tried this install on three different computers and two distributions. The current one is an hours-fresh install of 10.04 LTS 64 so everything OS-wise should be on the up-and-up. I particularly don’t understand the setup file printout and would LOVE some clarification there. This work is pretty important to my finishing out my MS thesis this summer.

Re: Software Install Problem: Bad fd number

Any ideas at all guys? I am pretty used to working in Ubuntu so I would like to keep my work there, but this little issue would definitely force me to migrate temporarily at least. I would MUCH rather not have to deal with the learning curve associated with learning another Linux OS just to finish out a relatively short-term task.

Re: Software Install Problem: Bad fd number

Just wanted to report that, on both Debian 5 and Fedora Core 12, I am receiving precisely the same error. I am going to give openSUSE 11.2 a try (since it is on one of my laptops), but I suspect this will largely go the same way as Ubuntu, Debian, and Fedora Core went.

Last edited by Nsight7; May 3rd, 2010 at 05:20 PM .

Re: Software Install Problem: Bad fd number

Okay, I am going to suppose that nobody has any suggestions on this given the lack of replies. I have emailed the developers of the software and I will continue fooling with the software, so if I find anything out regarding the installation of this simulation software, I will post back. Until then, thanks for your time!

Re: Software Install Problem: Bad fd number

The first thing I did was to remove all of the at-signs (@) from the makefiles. Then it was obvious.

Last edited by gmargo; May 4th, 2010 at 08:28 PM .

Re: Software Install Problem: Bad fd number

Thanks for the help! I actually fixed it too, but differently.

I went into Makefile.common and added the line

to the beginning of the file.

One must also make sure they have makedepend and thus need

Finally, once I got around that and started getting other errors that seemed related to the actual code, I had to add a couple of header files to each .cc file. It seems that the version of g++ they were running, which is like 5+ years old, would compile the code without the appropriate headers without spitting errors. Mine, however, would not. I think I mostly had to add:

Once would see exactly which declaration errors were made (stuff like ‘strcmp’ and ‘atof’ and the like), and then one could add the appropriate headers.

After all this was done it compiled no problem and I ran the code without issue. Next we shall see if I can interface it properly with geant4.

Источник

Долгий страт midnight commander в терминале Linux Mind

Всем привет! Столкнулся с любопытной проблемой: из-под обычного пользователя в терминале linux mint (cinnamon) долго запускается mc (секунд по 10-20). Однако если в командной строке написать «sudo mc» — то открывается моментально. Есть идеи, с чем это может быть связано?

Догадался выполнить strace:

тут вот поймался этот таймаут в 10 секунд

Запусти через стрейс, глянь что долго выполняется

В домашем и текущем каталоге очень много файлов?
Если в них много файлов то mc может начать тормозить.
Как решение используй команду cd в пустой или не очень большой каталог или запусти mc явно указав путь к каталогам:

mc path_to_dir1 parh_to_dir2

Нет, система практически пустая, ничего своего ещё не успел разместить.

Там вот в strace поймался таймаут, теперь не могу понять, что это значит. Что-то с hostname?

Опять проблема с hosts и DNS запросами?

В зависимости от настроек система пытается искать hostname через DNS.

Да вроде у меня имя хоста прописано в hosts на 127.0.0.1.

Я даже hostname себе поменял на IP адрес в локальной сети — один фиг, не помогает.

Какое содержимое /etc/hosts?

Судя по precmd() у вашего пользователя оболочка zsh.

Попробуйте запустить mc –nosubshell.

Да, так работает. Но если из mc попытаться отредактировать какой-то файл (mcedit) — опять timeout.

Выяснил ещё, что проблема наблюдается только у того пользователя, которого я сам создал через useradd. Видать, чего-то недосоздал.:(

Причём, опять же, если соединяться со сторонней системы к этой по ssh под именем этого пользователя — mc открывается быстро.

Ну так если «так работает» — может быть попытаться сменить shell на bash, или починить zsh? )

Ты в виртуалке запускаешь?

Покажи, что в /etc/hostname, покажи еще, что в /etc/resolv.conf.

127.0.0.1 localhost novamint-vmware novamint-vmware.domain novamint-vmware.localdomain

Попробуй не алиасы делать, а отдельные строчки для каждого хостнейма. Перезапустись.

И вот еще до кучи:

Да, в виртуалке. В hosts изначально было разными строками. Наоборот, я склеил, чтобы и этот вариант проверить.

По вашим ссылкам смотрел, сам многие из них находил. Но что-то пока они не помогли разобраться.

Повторюсь, проблема наблюдается только из-под одного пользователя. Если бы было что-то с hosts или dns, наблюдалось бы и у других пользователей.

Вот содержимое /etc/resolv.conf:

Повторюсь, проблема наблюдается только из-под одного пользователя. Если бы было что-то с hosts или dns, наблюдалось бы и у других пользователей.

Ну мне кажется, что все равно дело где-то с таймаутом DNS. А чем этот пользователь от других отличается? Я уже видел, что этот пользователь создан при помощи useradd. А другие пользователи как создавались? Откуда они? Проблема прав, может быть?

У тебя Mint. Значит, это производная Debian. Создай пользователя при помощи adduser, а не useradd, и проверь снова.

Прям разозлился, что аж Mint установил. Но не могу воспроизвести.

Явно же смущает:

Вы точно никаких «тем» zsh не устанавливали? Уж больно подозрительное у вас там что-то пытается нарисоваться в строке приглашения, нестандартное.

Такое впечатление, что этот precmd() пытается вызвать сценарий, рассчитанный на zsh, но вызывается dash, отваливается с ошибкой, а дальше уже получается таймаут из-за того, что вот эту ошибку (сам текст её) оно пытается искать в ваших hosts.

Ну. я бы так перевёл. Но, осторожно, у меня богатая фантазия.

Сделай Ctrl + Alt + F2 , далее логин пользователем и запуск mc. Если запуск быстрый, то трабла связана с X. Можно использовать mc —no-x11 .

аж Mint установил. Но не могу воспроизвести

Воспроизвёл.
Стыдно признаться, но всё что тут понаписано мной про zsh — ерунда полная. Абсолютная.

Поведение mc ровно как у вас, если у пользователя оболочка /bin/dash.

Самым простым решением будет вам — поменять оболочку для этого пользователя на /bin/bash.

Потому что «сложным решением» пока вообще даже фантазия не помогает, что можно сделать.

На текущий момент так:

В Ubuntu, Mint, ArchLinux — все с ядром 5.4 если запускать так:

В Debian с ядром 5.4 из бэкпортов — задержки нет.

Задержка эта живёт в коде /mc/src/subshell/common.c

Почему этот select работает нормально в Debian, но зависает и отваливается по таймауту в остальных при subshell=DASH — никаких мыслей нет.

Надо звать настоящих программистов за разъяснениями.

Поведение mc ровно как у вас, если у пользователя оболочка /bin/dash.

ТС пишет, что он создавал пользователя при помощи useradd. В Debian этот способ прописывает SHELL как /bin/sh или пустую строчку, если специально не указать —shell в командной строке.

Однако даже если прописывается /bin/sh, то странно: у меня в Debian (а что в Mint, надо проверить):

Если создавать пользователя при помощи adduser (а именно так рекомендуется делать https://wiki.debian.org/UserAccounts), то SHELL прописывается так, как он указан в /etc/adduser.conf, а по умолчанию в Debian там стоит прямо конкретно /bin/bash.

Достаточно проверить переменную SHELL. dash используется в Debian как non-interactive shell, а пользовательская оболочка по умолчанию bash. https://wiki.debian.org/Shell

UPD. Вот как раз может быть, что в Mint /bin/sh на /bin/dash указывает.

Всё правильно. adduser это обёртка над более суровым useradd. Кабы ТС пользователя добавлял этой обёрткой — был бы bash.

Вот свежеустановленный (позавчера) Mint:

Поэтому через useradd ТС получил пользователя с dash.

Поэтому и в трассировке ругань на /bin/sh, который dash. (Но я ошибся — эта ругань совершенно безобидная и не должна была смущать.)

Тут вроде всё просто и понятно. Вот с select — не понятно.

dash используется в Debian как non-interactive shell, а пользовательская оболочка по умолчанию bash

Вот свежеустановленный (с неделю назад) Debian10:

У всех дебианов по-умолчанию должен быть dash. Всегда так было.

Ненаучным тыком — разница между Arch и Ubuntu/Mint:

При SHELL=/bin/dash mc

На tty2 Ubuntu/Mint также зависает на 10 секунд, как и из DE.

А вот Arch — не(. ) зависает на tty2. Только в эмуляторе терминала DE.

У всех дебианов по-умолчанию должен быть dash. Всегда так было.

Не знаю, не помню, когда это произошло, но дело в том, что у меня Debian обновляется еще со времен pre-Etch (если судить по самым старым файлам, то 2005 год), то есть когда Etch еще не вышел. С тех пор заново я ничего не ставил, а просто накатывал. Поэтому у меня ситуация может оказаться вот такой, какая она есть. Я не помню, когда dash стал по умолчанию. Вроде в Ubuntu он по умолчанию стал только с версии 6.10. Значит, в 2006 году. И не помню что-то, чтобы я менял этот линк.

Возможно я погорячился с «Всегда так было».

Честнее сказать «Всегда только так и видел». Сейчас максимально старый — Debian6 в виртуалке запустил. Там тоже dash.

Что было до squeeze не знаю.

Возможно я погорячился с «Всегда так было».

Я вот сейчас запустил dpkg-reconfigure dash и он мне предложил заменить /bin/sh в dash, но можно отказаться. Видимо, он когда-то давно тоже предлагал, но я не согласился. Этого я уже не помню. При обновлении на последний stable ничего такого точно не было.

Почему этот select работает нормально в Debian, но зависает и отваливается по таймауту в остальных при subshell=DASH — никаких мыслей нет.

Откуда ошибка идет там более-менее понятно. В исходном коде mc какая-то фигня (/src/subshell/common.c). Там в subshell, если он является dash, передается pwd>&%d , чтобы prompt сформировать. Вместо %d подставляется subshell_pipe[WRITE]. dash на этот subshell_pipe[WRITE] выдает ошибку типа:

Скорее всего, файловый дескриптор, который передается в скрипт, состоит из двух цифр, а dash их не понимает. Похоже, он только от 0 до 9 принимает.

В общем, subshell умирает раньше времени из-за ошибки, не дойдя до конца. А mc сидит в select с тамаутом 10 секунд.

Спасибо. Вполне похоже на правду.

Я по старой рабоче-крестьянской привычке тупо принтов в код навставлял. В смысле — принтов в файл-лог. Поэтому сомнений-то нет в месте затыка.

Сейчас попробую в коде зашитое приглашение для dash поменять.

Всё это привело к тому, что теперь в одной системе порт 53 может слушать несколько разных ресолверов, причём для избежания конфликтов NetworkManager и systemd-resolved используют вместо 127.0.0.1 другие IP-адреса в loopback-сети:

Проблема заключается в том, что с systemd NetworkManager пытается дружить сильнее разумного:

Скорее всего, файловый дескриптор, который передается в скрипт, состоит из двух цифр, а dash их не понимает. Похоже, он только от 0 до 9 принимает.

Всё так. Добавил в свой лог запись значения subshell_pipe[WRITE] во время формирования строки приглашения.

Запускаю этот самосборный mc с принтами в ArchLinux так:

• Если запускать из эмулятора терминала — там 10, и висит до таймаута.
• Если запускать из tty2 — там 9, и нормально стартует.
• Если убрать из исходников «pwd>&%d;», то висит в любом случае — хоть 10, хоть 9 в subshell.

Если убрать из исходников «pwd>&%d;», то висит в любом случае — хоть 10, хоть 9 в subshell.

В случае ошибки ни один байт не попадает в subshell_pipe[WRITE], так как pwd валится из-за ошибки fd. И в случае отсутствия команды pwd тоже ничего в subshell_pipe[WRITE] не попадает. Ни одного байта. А mc, похоже, хоть чего-то там ждет максимум 10 секунд.

Ради любопытства — перезагрузился в свой Debian (который не виртуальный, настоящий, с KDE) — там и в эмуляторе konsole, и в tty2 subshell_pipe[WRITE] = 9. Потому и с dash проблем там нет.

Забавно, наверное что-то про GNOME(xfce4, cinnamon — не суть) тогда это 10.

Пойду, попытаюсь нарыть откуда в гномах берётся 10 в subshell_pipe.

Окончательно «всё, наигрался»:

В коде mc SHELL_DASH можно сделать по аналогии с SHELL_TCSH, через mkfifo и перенаправлять pwd не в номер файла, а в имя этого канала (как и у tcsh опять же).

Кажется всё нормально работает.

В реальной жизни скорее всего это никому не нужно. Но так, в порядке просвещения — это было занимательно.

ТСу, конечно, просто поменять shell на /bin/bash у проблемного пользователя.

То, что там fd больше 9, никакой ошибки нет. Проблема, да, в самом скрипте. Не учли эту особенность dash [1]. Понятно, что тут только однострочник надо как-то переделывать, потому что нельзя было рассчитывать, что dash должен съесть fd больше 9. Скорее всего, у того, кто скрипт закоммитил, просто не проявился баг.

В реальной жизни скорее всего это никому не нужно. Но так, в порядке просвещения — это было занимательно.

Полезный выход из этой истории — поискать похожий баг в багзилле mc или зарепортить, приложив патч. Учитывая, что dash вообще редко у кого является интерактивным шеллом, по ошибке если только. А среди тех, у кого он оказался оболочкой по умолчанию, не нашлось людей, которые стали разбираться или могли это сделать. Скорее, просто забили или поменяли SHELL потом.

[1] На самом деле, это допустимая трактовка POSIX. Не обязаны.

Open files are represented by decimal numbers starting with zero. The largest possible value is implementation-defined; however, all implementations shall support at least 0 to 9, inclusive, for use by the application. These numbers are called «file descriptors»

Источник

    LINKER     hbirt_test.bin
    LINKER     hbicore.bin
    LINKER     hbicore_test.bin
sh: 1: Syntax error: Bad fd number
sh: 1: Syntax error: Bad fd number
sh: 1: Syntax error: Bad fd number
sh: 1: Syntax error: Bad f    LINKER     hbirt_test.bin
    LINKER     hbicore.bin
    LINKER     hbicore_test.bin
sh: 1: Syntax error: Bad fd number
sh: 1: Syntax error: Bad fd number
sh: 1: Syntax error: Bad fd number
sh: 1: Syntax error: Bad fd number
cd build/buildpnor/ && /usr/bin/make --no-print-directory --no-builtin-rules --n
o-builtin-variables buildpnor
make[6]: Nothing to be done for 'buildpnor'.
true
../src/build/trace/tracehash_hb.pl -c -d ../obj -s ../img/hbotStringFile
    GENLIST    hbicore
    GENLIST    hbicore_test
    GENLIST    hbirt_test
    MAKE       kernel IMAGE
d number
cd build/buildpnor/ && /usr/bin/make --no-print-directory --no-builtin-rules --n
o-builtin-variables buildpnor
make[6]: Nothing to be done for 'buildpnor'.
true
../src/build/trace/tracehash_hb.pl -c -d ../obj -s ../img/hbotStringFile
    GENLIST    hbicore
    GENLIST    hbicore_test
    GENLIST    hbirt_test
    MAKE       kernel IMAGE