Что означают верхние/младшие биты?
Обратите внимание, что команды [[(, [иtest)такие же, как и любые другие. Таким образом, вам нужно &&, чтобы выполнить echoтолько в том случае, если [[завершится успешно.
ssh "root@${ipserver}" "[[ -d ${fullpathfile}/node_modules ]] && echo "Directory exist" || cd ${fullpathfile} && npm install "
Тем не менее, заключение ряда команд в двойные кавычки, подобные этому, может довольно быстро наскучить, особенно если имя вашего каталога содержит пробелы или вашим командам нужны собственные аргументы в кавычках.
Чтобы не было головной боли, лучше установить на сервер небольшой скрипт (, например, как "$HOME/bin/do _npm _install.sh" ), который делает то, что вам нужно, затем вызовите это с помощью ssh, например
ssh "root@${ipserver}" "bash ~/bin/do_npm_install.sh"
Давайте возьмем один пример, используя документ , на который вы ссылаетесь в своем вопросе для справки :, поле i_uidимеет размер __le16и описывается как Lower 16-bits of Owner UID. Если система, которая создала эту файловую систему, допускает только 16-битные -идентификаторы пользователей, тогда все идентификаторы пользователей могут поместиться в поле i_uid:__le16действительно означает «маленькие -порядковые 16 бит». в вашей аналогии, если у вас может быть только двухзначное число -и стоимость составляет 29 долларов, все готово, потому что это подходит.
Если используются 32 -битные идентификаторы пользователей (Я почти уверен, что ни одна система не использует более крупные идентификаторы ), тогда 32 -битные идентификаторы пользователей не поместятся в поле размера __le16, так что 32 бита разбиваются на две части по 16 -бит. Если мы пронумеруем биты от 0 для самого младшего бита до 31 для самого старшего бита (, что просто является нашим соглашением здесь для однозначности ), тогда биты 0 -15 («младшие» -порядок» биты )помещаются в поле i_uid, но биты 16 -31 (биты «старшего -порядка» )не подходят и должны быть куда-то еще :в Linux, который использует 32-битные -идентификаторы пользователей, они заканчиваются в подполе l_i_uid_highполя osd2индексного дескриптора. По вашей аналогии, если стоимость составляет 129 долларов, но у вас есть два -цифровых поля,тогда 29будет помещаться в младший разряд -второго порядка -, а 01— в старший -разряд второго порядка -.
Несколько дополнительных моментов :отмечают, что все поля имеют «маленький -порядок следования байтов» -, если поле состоит из более чем одного байта (, например. __le16состоит из двух байтов ), затем наименее -значащий байт идет первым, а старший -значащий байт идет вторым по порядку, но они являются соседними. То есть независимо от порядка байтов ЦП системы :таким образом, способ размещения файловой системы на диске не зависит от ЦП, который ее создал; вы можете прочитать эту файловую систему в другой системе с противоположным порядком байтов, если хотите (с оговоркой, что версии ext4, работающие в двух системах, должны быть совместимы ).
Также обратите внимание, что младшие 16 бит -порядка (= 2 байта )идентификатора пользователя и 16 бит старшего порядка -идентификатора пользователя хранятся в двух местах на диске, которые не смежный :первый находится по смещению 0x2 от начала инода, а второй находится по смещению 0x74 + 0x4 от начала инода :0x74 там, где 12 -поле байта i_osd2начинается, а 0x4 — это смещение l_i_uid_highот начала поля i_osd2. Вероятно, это произошло потому, что в какой-то момент «во всем мире были 16 -битных идентификаторов пользователей», поэтому ранние файловые системы резервировали только первое поле для идентификатора пользователя. Когда возникла необходимость использовать 32 -битных идентификатора пользователя, вторые 16 бит нельзя было разместить рядом, так как другие поля уже были там (в данном случае поле i_size, которое изначально было ограничено 32 -бит, но это тоже оказалось слишком мало, поэтому в конце концов был добавлен i_size_field, чтобы получить еще 32 бита размера -см. смещение 0x6C в иноде ),поэтому он был помещен в (, вероятно, )первое место в иноде, которое не использовалось и было доступно для использования.
Большая часть этой сложности была вызвана соображениями обратной -совместимости (ext4 хотела иметь возможность читать файловые системы ext3 без необходимости каких-либо специальных действий пользователя )и желанием приспособиться к будущему расширению. Оглядываясь задним числом 20/20, можно было бы собрать все разрозненные фрагменты, и вы бы увидели, например,. i_uidтипа __le32вместо того, чтобы разбивать его на две части. Но это то, что вы должны делать, чтобы двигаться вперед, не отказываясь от всего, что было раньше.