1.1, Аноним (-), 00:14, 17/09/2016 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– |
> Bash теперь сохраняет статус выхода только для асинхронных заданий, что нарушает совместимость с прошлыми версиями в которых сохранялись статусы для всех заданий. Таким образом теперь нельзя использовать команду wait для получения статуса предыдущей синхронной команды; | |
|
|
3.21, РОСКОМУЗОР (?), 11:17, 17/09/2016 [^] [^^] [^^^] [ответить]
| +5 +/– |
Данное изменение предложено лично Бараком Обамой. Юзайте православную версию, там всё по старому.
| |
|
2.24, freehck (ok), 12:58, 17/09/2016 [^] [^^] [^^^] [ответить]
| +7 +/– |
Хм. wait для получения статуса *синхронной* команды? А кто его вообще для этого юзал? Как он умудрился это сделать, и главное -- зачем это понадобилось?
Я вот думал, что wait только для асинхронных команд можно использовать. Или отдельные умельцы шлют SIGCONT остановленному процессу синхронной команды, и натравливают на него wait?
| |
|
3.40, EHLO (?), 14:09, 18/09/2016 [^] [^^] [^^^] [ответить]
| +2 +/– |
> Я вот думал, что wait только для асинхронных команд можно использовать. Или
> отдельные умельцы шлют SIGCONT остановленному процессу синхронной команды, и натравливают
> на него wait?
Остановленный процесс это уже асинхронная команда.
Я с интересом для себя обнаружил, что:
$bash -c 'echo $$;exit 33'
2737
$bash -c 'echo $$;exit 44'
2738
$wait 2738 ; echo $?
44
$wait 2737 ; echo $?
33
$wait 2738 ; echo $?
44
Отключили вероятно для оптимизации. Помнить все PIDы может оказаться накладно в гипотетической ситуации.
| |
|
|
|
|
3.6, leap42 (ok), 02:33, 17/09/2016 [^] [^^] [^^^] [ответить]
| +1 +/– |
vi-mode или emacs? с последним уже много лет проблем не замечал. может, дистро-специфичные проблемы? баг уже отрепортили?
| |
|
|
5.12, Аноним (-), 06:45, 17/09/2016 [^] [^^] [^^^] [ответить]
| +/– |
Автор имел ввиду не пойми что. Debian Jessie, ZSH 5.0.7, проблем не наблюдаю.
| |
|
4.18, Виталик (??), 09:57, 17/09/2016 [^] [^^] [^^^] [ответить]
| +1 +/– |
Короче рассказываю. Как была шумиха вокруг shellshock я решил что баш не безопасен и пора сваливать на zsh (я тогда только недавно перешел на GNU+Linux). Так как настраивать с нуля желания не было скачал с гитхаба oh-my-zsh, так что возможно вина в глючности лежит не на самом zsh, а на этом конфиге)
Вот список глюков встреченных за 2 дня использования:
- при длинном названии working directory шрифт коцался и становился нечитаемым
- если нажать энтер 2 раза быстро после ответа на какой-то readline вопрос все коцалось и писалось не на тех рядках, где должно
- иногда он просто не работал, окошко терминала просто становилось пустым и надо было открывать новую вкладку
При том всем на макбуке мамки oh-my-zsh работает отлично без подобных проблем.
В общем я потом попробовал fish и остался им доволен аки слон, там все стабильно, быстро и удобно. С тех пор пользуюсь им чего и вам советую.
P.S. на сайте zsh оглавление мануала размечено с помощью тегов definition list, уже одно это говорит что у авторов не в порядке с головой и чего стоит ожидать от их продукта.
| |
|
5.20, Аноним (-), 11:06, 17/09/2016 [^] [^^] [^^^] [ответить]
| +/– |
oh-my-zsh
использовать крайне не рекомендуется, по причие тормазнутости.
посмотрите сколько времени идет запуск.
for i in $(seq 1 10); do /usr/bin/time zsh -i -c exit; done
| |
5.22, Аноним (-), 11:54, 17/09/2016 [^] [^^] [^^^] [ответить]
| +/– |
oh-my-zsh -- та ещё помойка с понадёрганными со всего интернета рецептами для плагинов. Для начала лучше использовать grml.
| |
5.23, freehck (ok), 12:40, 17/09/2016 [^] [^^] [^^^] [ответить]
| +/– |
oh-my-zsh -- помойка, у которой дефолты начисто подвешивают консоль (Зато красиво! Им, понимешь ли, красиво хотелось, а то, что по секунде ждать следующего приглашения консоли - это им плевать).
Мне лично хватает git://github.com/zsh-users/zsh-syntax-highlighting.git
Плюс разумеется bash-completion и своего немного там понавешал.
| |
5.27, Аноним84701 (?), 16:29, 17/09/2016 [^] [^^] [^^^] [ответить]
| +2 +/– |
> P.S. на сайте zsh оглавление мануала размечено с помощью тегов definition list,
> уже одно это говорит что у авторов не в порядке с головой и чего стоит ожидать от их продукта.
Нет, это говорит о том, что уважаемому диванному аналитику опеннета стоило посмотреть хотя бы на cлона^W мета-данные, прежде чем делать так далеко идущие выводы:
> <!-- Created by GNU Texinfo 6.0, http://www.gnu.org/software/texinfo/ -->
> <meta name="Generator" content="texi2any"> | |
|
|
|
|
1.11, intelfx (ok), 05:11, 17/09/2016 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
'mapfile -d' -- вау, годно!
Ещё бы запилили применение нескольких модификаторов подстановки за один раз (как в zsh, через двоеточие) -- цены бы не было.
| |
|
|
3.43, Аноним (-), 20:24, 18/09/2016 [^] [^^] [^^^] [ответить]
| +/– |
> в армии есть, но там терминалов нет.
Если бы там побывал, то знал бы, что терминалы там есть. Ах с советских времён.
| |
|
2.35, Аноним (-), 01:58, 18/09/2016 [^] [^^] [^^^] [ответить]
| +1 +/– |
Бери баш и ebash. Очевидно же. Не нравится - пиши свой. Как сделаешь человеческим, не удивляйся реакции человеков.
А если серьезно, ты скорее всего не прочел полную справку на баш, он вполне, поэтому и стал стандартом.
| |
|
1.31, Онаним (?), 23:45, 17/09/2016 [ответить] [﹢﹢﹢] [ · · · ]
| –3 +/– |
Кстати а может кто объяснить зачем люди ломают мозги и пишут bash-скрипты когда есть Python и много других более интуитивных и более мощных языков? Просто любопытно.
| |
|
2.33, Аноним (-), 01:21, 18/09/2016 [^] [^^] [^^^] [ответить]
| +/– |
А что тут объяснять? Это очевидно любому специалисту. Где-то удобнее bash, где-то python.
| |
2.34, Led (ok), 01:52, 18/09/2016 [^] [^^] [^^^] [ответить]
| +2 +/– |
> когда есть Python и много других более интуитивных и более мощных
> языков?
"понятный даже дебилу" != "интуитивный и мощный для не-дебила".
| |
2.36, Аноним (-), 02:06, 18/09/2016 [^] [^^] [^^^] [ответить]
| +1 +/– |
Любой вопрос возникает от незнания. В данном случае ты не знаешь, что непосредственно в шеле можно выполнять последовательности команд, а после выполнения, их полезно куда-то сохранить. Так и появляются bash-скрипты. Когда в командной строке синтаксис python дойдёт до степени удобства bash, то можно будет обсудить поставленный вопрос, а пока сравнение из серии сравнения ежа с носорогом.
| |
2.38, angra (ok), 11:02, 18/09/2016 [^] [^^] [^^^] [ответить]
| +6 +/– |
Причин несколько.
1. Самая распространенная заключается в незнании большинством админов ЯП общего назначения вроде питона, перла, рубина.
2. Некоторые скриптовые языки чаще всего отбрасываются из-за их отсутсвия по дефолту в любом линуксе, в отличии от перла и питона. Прощай рубин.
3. Скрипт зачастую вырастает из однострочника, а значит с питоном тоже прощаемся.
4. Некоторые задачи таки удобней сделать на шелле, так как в них больше половины работы приходится на внешние утилиты.
| |
|
3.41, Аноним (-), 18:07, 18/09/2016 [^] [^^] [^^^] [ответить]
| –1 +/– |
Полностью согласен. Почти всегда мои башескрипты начинаются с однострочника, но иногда, на втором часе правок и попыток я говорю себе "лучше бы сразу взял Питон". Но когда делать на последнем лень, часто спасает python -c и inline script.
| |
3.57, Масик (?), 09:03, 21/09/2016 [^] [^^] [^^^] [ответить]
| +/– |
Не знаю как у вас, а наши админы знают perl и python иногда не хуже разработчиков. Но пользуются часто и bash-скриптами.
| |
|
|
3.47, gnu hater (?), 08:50, 19/09/2016 [^] [^^] [^^^] [ответить]
| –1 +/– |
python поставляется почти со всеми дистрами(по крайней мере популярными) так же как и perl.
| |
|
4.48, Happy_demon (??), 09:10, 19/09/2016 [^] [^^] [^^^] [ответить]
| +/– |
не скажу за линуксы, но во фре, начиная с версии кажется 6что-то_там перла по умолчанию нет.
| |
|
|
6.52, _ (??), 18:28, 19/09/2016 [^] [^^] [^^^] [ответить]
| –1 +/– |
Всё правильно известно.
Ещё в до-мезозойскую эру отцы основатели сказали что то типа интерактивным шеллом можешь иметь что хочешь, но для скриптов пользуй #!/bin/sh Luke! And Power will be with you ...
(ну и ещё много какашек на csh как шелл для скриптов ... да кто это помнит уже :)
У меня например руки сами бактики набирают вместо $() :)
Хотя по нынешним временам, когда зайдя по ssh в 99% увидишь линукс и баш ... стоит ли йУнным париЦЦо?!
| |
|
7.53, Led (ok), 21:12, 19/09/2016 [^] [^^] [^^^] [ответить]
| +1 +/– |
> У меня например руки сами бактики набирают вместо $() :)
$() - POSIX shell
Но ты и дальше "бактики" набивай...
| |
|
|
|
4.55, Аноним (-), 11:17, 20/09/2016 [^] [^^] [^^^] [ответить]
| +/– |
И ввиду "некоторых несовместимостей" (не)работает по разному, с utf-8 тоже интересная история.
| |
|
|
4.56, Аноним (-), 07:13, 21/09/2016 [^] [^^] [^^^] [ответить]
| –2 +/– |
> Распространённое заблуждение.
Конечно, ведь я написал ещё про sh. Только не говорите, что busybox не везде есть. Никогда не поверю.
| |
|
5.58, Аноним (-), 21:50, 21/09/2016 [^] [^^] [^^^] [ответить]
| +/– |
sh есть везде. А sh == bash -- распространенное забдуждение. Я вас не правильно понял.
| |
|
|
|
|
1.59, Аноним (-), 09:42, 23/09/2016 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Ключевая фраза: "Bash теперь сохраняет статус выхода только для асинхронных заданий, что нарушает совместимость с прошлыми версиями"...
Синдром Поттеринга -- страшная заразная болезнь нашего времени.
| |
1.60, jidckii (?), 16:27, 20/03/2017 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Я правильно понимаю, что вот такая конструкция у меня перестанет работать с версии 4.4 ??
<code> if [[ -d "$dalet_path" ]];then
cp $end_path$end_file_name.$CONTAINER $dalet_path$FORMAT_PATH >> $LOG_FILE 2>&1 & pid_cp=$!
else
log_info "\e[1;31m Ошибка при копировании в DALET, путь не найден \e[0m"
fi
if [[ -d "$frank_path$date_dir" ]];then
cp -R $source_path* $frank_path$date_dir$v_hd >> $LOG_FILE 2>&1 & pid_cp1=$!
else
log_info "\e[1;31m Ошибка при копировании на FRANK, путь не найден \e[0m"
fi
if [[ -d "$frank_path$date_dir" ]];then
cp $end_path$end_file_name.$CONTAINER $frank_path$date_dir$dlya_montaja >> $LOG_FILE 2>&1 & pid_cp2=$!
else
log_info "\e[1;31m Ошибка при копировании на FRANK, путь не найден \e[0m"
fi
wait $pid_cp2
if [[ "$?" -ne 0 ]]; then
log_info "\e[1;31m Ошибка во время копирования готового на FRANK \e[0m "
return 1
fi
wait $pid_cp1
if [[ "$?" -ne 0 ]]; then
log_info "\e[1;31m Ошибка во время копирования исходников на FRANK \e[0m "
return 1
fi
wait $pid_cp
if [[ "$?" -ne 0 ]]; then
log_info "\e[1;31m Ошибка во время копирования готового в DALET \e[0m"
return 1
fi
</code>
| |
|