Для чего нужна переменная $ BASH_COMMAND?

Несмотря на то, что я опаздываю, я хочу добавить конкретный случай:

Заново открыть окно панели инструментов

Если вам нужно снова открыть панель инструментов, используйте комбинацию клавиш Ctrl+B или (GIMP версия 2.8.14):

Windows > Toolbox

На этой панели инструментов вы можете изменить цвет, просто щелкнув по цвету переднего плана или фона, как показано @OrangeTux и @Warren Hill. [!d3 ]

1
задан 20 August 2014 в 23:24

3 ответа

Теперь, когда Q3 был дан ответ (правильно, на мой взгляд: BASH_COMMAND полезен в ловушках и почти нигде), давайте дадим Q1 и Q2 выстрел.

Ответ на Q1: правильность вашего предположения неразрешима. Истина ни о точках пули не может быть установлена, поскольку они спрашивают о неуказанном поведении. По его спецификации значение BASH_COMMAND устанавливается на текст команды на время выполнения этой команды. Спецификация не указывает, каково ее значение в любой другой ситуации, то есть когда никакая команда не выполняется. Он может иметь любое значение или вообще ничего.

Ответ на Q2 «Если нет, как еще можно объяснить поведение в приведенной выше последовательности команд?» затем следует логически (если несколько педантично): это объясняется тем, что значение BASH_COMMAND не определено. Поскольку это значение не определено, оно может иметь любое значение, которое точно соответствует последовательности.

Postscript

Есть один момент, когда я думаю, что вы действительно попадаете в мягкое пятно в спецификации. Это где вы говорите:

Даже когда я делаю MYVARIABLE = $ BASH_COMMAND прямо в начале моей $ PROMPT_COMMAND, тогда MYVARIABLE содержит строку MYVARIABLE = $ BASH_COMMAND, потому что назначение тоже является командой.

Как я прочитал страницу bash man, бит в курсиве не соответствует действительности. В разделе SIMPLE COMMAND EXPANSION объясняется, как сначала выделены назначения переменных в командной строке, а затем

Даже когда я делаю MYVARIABLE = $ BASH_COMMAND прямо в начале моего $ PROMPT_COMMAND, тогда MYVARIABLE содержит строку MYVARIABLE = $ BASH_COMMAND, потому что назначение тоже является командой.

Если имя команды не было [другими словами, были только назначения переменных), назначения переменных влияют на текущий shell.

Это говорит мне о том, что назначения переменных не являются командами (и поэтому освобождаются от появления в BASH_COMMAND), как на других языках программирования. Это также объясняет, почему в выводе set, set нет строки BASH_COMMAND=set, по существу являющейся синтаксическим «маркером» для присваивания переменной.

Если есть имя команды слева после расширения, выполнение продолжается, как описано ниже. В противном случае команда выйдет.

OTOH, в последнем абзаце этого раздела говорится

6
ответ дан 24 May 2018 в 04:28
  • 1
    Просто потому, что какое-то предположение не может быть установлено, не означает, что оно неверно. Эйнштейн предположил, что скорость света одинакова для любого наблюдателя (с любой скоростью) как одна фундаментальная гипотеза для теории относительности; который не может быть установлен, но это не значит, что оно неверно. Свойства "могут быть установлены" и "правильно" являются ортогональными. В лучшем случае вы могли бы сказать «Мы не знаем, правильно ли это, потому что он не может быть установлен». Кроме того, это указано : это текущая команда во время выполнения. Поэтому, если я набираю set, я должен видеть BASH_COMMAND='set' где-то в этом выпуске, который – Malte Skoruppa 21 August 2014 в 19:07
  • 2
    ... однако это не так. Хотя это во время выполнения команды set . Следовательно, согласно спецификациям, он должен работать. Так ли это, что реализация неверно подчиняется спецификациям или я неправильно понимаю спецификации? Нахождение ответа на этот вопрос является своего рода целью Q1. +1 для вашей постскриптум :) – Malte Skoruppa 21 August 2014 в 19:10
  • 3
    @MalteSkoruppa Хорошие моменты. Исправил ответ соответственно и добавил замечание о set. – zwets 22 August 2014 в 18:58
  • 4
    Возможно, что в интерпретаторе bash set не является «командой». Так же, как = не является «командой». Обработка текста, следующего за этими маркерами, может иметь совершенно другую логику, чем обработка «команды». – DocSalvager 27 August 2014 в 11:37
  • 5
    Хорошие моменты от вас обоих. :) Возможно, что set не считается «командой». Я бы не подумал, что $BASH_COMMAND окажется во многих обстоятельствах столь неопределенным. Я думаю, по крайней мере, мы установили, что страница man определенно могла бы быть более ясной об этом;) – Malte Skoruppa 27 August 2014 в 14:41

Изобретательное использование для $ BASH_COMMAND

Недавно нашло это впечатляющее использование $ BASH_COMMAND в реализации макроподобной функциональности.

Это основной трюк псевдонима и заменяет использование ловушки DEBUG. Если вы прочтете часть предыдущей записи об ловушке DEBUG, вы узнаете переменную $ BASH_COMMAND. В этом сообщении я сказал, что он был настроен на текст команды перед каждым вызовом ловушки DEBUG. Ну, оказывается, он установлен перед выполнением каждой команды, ловушкой DEBUG или нет (например, запустите «эхо» эту команду = $ BASH_COMMAND », чтобы узнать, о чем я говорю). Назначив ему переменную (только для этой строки), мы берем BASH_COMMAND в самой внешней области команды, которая будет содержать всю команду.

У автора впечатляющее использование $ BASH_COMMAND также дает хороший фон при реализации метода с использованием DEBUG trap. [F2] устраняется в улучшенной версии.

2
ответ дан 24 May 2018 в 04:28
  • 1
    +1 Я, наконец, обошел эти две статьи. Вау! Что читать! Очень просветительская. Этот парень - баш гуру ! Престижность! Это также отвечает моему комментарию на ответ Дмитрия о том, можно ли $BASH_COMMAND использовать в контексте, отличном от trap. И какое использование! Используя его для реализации макрокоманд в bash - кто бы мог подумать, что это возможно? Спасибо за указатель. – Malte Skoruppa 20 September 2014 в 20:51

По-видимому, общее использование для ловушки ... debug - улучшить заголовки, которые появляются в списке окон (^ A), когда вы используете «экран».

Я пытался сделать «screen», «windowlist» более удобен, поэтому я начал искать статьи, ссылающиеся на «trap ... debug».

Я обнаружил, что метод с использованием PROMPT_COMMAND для отправки «нулевой последовательности названий» не работает ну, так что я вернулся к методу отладки ...

Вот как вы это делаете:

1 Скажите «screen» искать escape-последовательность (включите ее) поместив «shelltitle» $ | bash: '»в« $ HOME / .screenrc ».

2 Отключите распространение ловушки отладки в под-оболочках. Это важно, потому что если она включена

3 Отправить escape-последовательность заголовка для «экрана» для интерпретации: trap 'printf "\ ek $ (date +% Y% m% d% H% M% S) $ (whoami) @ $ (имя хоста): $ (pwd) $ {BASH_COMMAND} \ e \ "'" DEBUG "

Это не идеально, но помогает, и вы можете использовать этот метод для размещения буквально anyt hi-hing вам нравится в заголовке

См. следующий «список окон» (5 экранов):

Num Name Flags

1 bash: 20161115232035 mcb @ ken007: / home / mcb / ken007 RSYNCCMD = "sudo rsync" myrsync.sh -R -r "$ {1}" "$ {BACKUPDIR} $ {2: +" / $ {2} "}" $ 2 bash: 20161115230434 mcb @ ken007: / home / mcb / ken007 ls --color = auto -la $ 3 bash: 20161115230504 mcb @ ken007: / home / mcb / ken007 cat bin / psg.sh $ 4 bash: 20161115222415 mcb @ ken007: / home / mcb / ken007 ssh ken009 $ 5 bash: 20161115222450 mcb @ ken007: / home / mcb / ken007 mycommoncleanup $

0
ответ дан 24 May 2018 в 04:28

Другие вопросы по тегам:

Похожие вопросы: