Разделение файлов
Разделить по размеру
Если вы хотите разбить большой файл на маленькие файлы и выбрать имя и размер маленьких выходных файлов, это способ.
split -b 500M videos\BigVideoFile.avi SmallFile.
Таким образом вы выбираете разделение одного большого файла на более мелкие части по 500 МБ. Также вы хотите, чтобы имена файлов деталей были SmallFile. Обратите внимание, что вам нужна точка после имени файла. Результатом должно быть создание новых файлов, подобных этому:
SmallFile.ab SmallFile.ad SmallFile.af SmallFile.ah SmallFile.aj
SmallFile.aa SmallFile.ac SmallFile.ae SmallFile.ag SmallFile.ai SmallFile.ak
...
Разделить по количеству строк
Таким образом вы разделите текстовый файл на файлы меньшего размера, ограниченные 50 строками.
split -l 50 text_to_split.txt
Результат должен быть примерно таким:
xaa xab xac...
Разделить по байтам
Разделить на небольшие файлы с произвольным размером небольших файлов в байтах:
split -b 2048 BigFile.mp4
Результат должен быть аналогичен результату Разбиение по количеству строк .
Объединение файлов
Вы можете объединить файлы двумя способами. Первый из них:
cat SmallFile.* > OutputBigVideoFile.avi
или с:
cat SmallFile.?? > OutputBigVideoFile.avi
Примечание.:При объединении файлов маленькие файлы не должны быть повреждены. Также все небольшие файлы (части )должны находиться в одном каталоге.
Файл cookie xauth хранится во временном файле (~/.xauthXXXX
), который удаляется, когда sudo
возвращает (, например. после завершения команды sudo xauth info
).
Предлагаю вам взглянуть на исходный код модуляpam_xauth
:
#define XAUTHTMP ".xauthXXXXXX"
...
int
pam_sm_open_session (pam_handle_t *pamh, int flags UNUSED,
int argc, const char **argv)
{
...
/* Generate the environment variable
* "XAUTHORITY=<homedir>/filename". */
if (asprintf(&xauthority, "%s=%s/%s",
XAUTHENV, tpwd->pw_dir, XAUTHTMP) < 0) {
...
fd = mkstemp(xauthority + sizeof(XAUTHENV));
...
cookiefile = strdup(xauthority + sizeof(XAUTHENV));
/* Save the filename. */
if (pam_set_data(pamh, DATANAME, cookiefile, cleanup) != PAM_SUCCESS) {
...
int
pam_sm_close_session (pam_handle_t *pamh, int flags UNUSED,
int argc, const char **argv)
{
...
if (pam_get_data(pamh, DATANAME, &data) != PAM_SUCCESS)
return PAM_SUCCESS;
cookiefile = data;
...
if (unlink(cookiefile) == -1 && errno != ENOENT)
pam_syslog(pamh, LOG_WARNING, "Couldn't remove `%s': %m", cookiefile);
Что касается pkexec
, я не думаю, что вы должны запускать приложения X11 с помощью pkexec
. Плохо то, что вы можете запускать их с помощью sudo
;-)
Учитывая, что вам не нужно общее решение, т. е. вы ищете хак и не желаете надежного решения, это кажется довольно хакерским -и тем не менее дает правильное решение. вывод, по крайней мере, если вводимый вами пример является самым сложным случаем, с которым вы можете столкнуться:
#!/usr/bin/env bash
set -o posix
grep '^[[:blank:]]*Issuer:' |
sed -Ee 's/^.* O[[:blank:]]*=[[:blank:]]*("[^"]*"|[^",]*),.*/\1/'
Даже как хак, я уверен, что это можно улучшить, если есть необходимость.
Приведенный выше код почти совместим с POSIX -и работает на моей системе, отличной от -GNU.
$ grep -w Issuer: /usr/local/etc/ssl/cert.pem | head -5; \
echo '...'; grep -w Issuer: /usr/local/etc/ssl/cert.pem | tail -5
Issuer: C = ES, O = FNMT-RCM, OU = AC RAIZ FNMT-RCM
Issuer: C = ES, O = FNMT-RCM, OU = Ceres, organizationIdentifier = VATES-Q2826004J, CN = AC RAIZ FNMT-RCM SERVIDORES SEGUROS
Issuer: CN = ACCVRAIZ1, OU = PKIACCV, O = ACCV, C = ES
Issuer: C = IT, L = Milan, O = Actalis S.p.A./03358520967, CN = Actalis Authentication Root CA
Issuer: C = US, O = AffirmTrust, CN = AffirmTrust Commercial
...
Issuer: C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST Network, CN = USERTrust ECC Certification Authority
Issuer: C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST Network, CN = USERTrust RSA Certification Authority
Issuer: C = US, O = "VeriSign, Inc.", OU = VeriSign Trust Network, OU = "(c) 1999 VeriSign, Inc. - For authorized use only", CN = VeriSign Class 1 Public Primary Certification Authority - G3
Issuer: C = US, O = "VeriSign, Inc.", OU = VeriSign Trust Network, OU = "(c) 1999 VeriSign, Inc. - For authorized use only", CN = VeriSign Class 2 Public Primary Certification Authority - G3
Issuer: C = US, OU = www.xrampsecurity.com, O = XRamp Security Services Inc, CN = XRamp Global Certification Authority
$./test.sh < /usr/local/etc/ssl/cert.pem | head -5; \
echo '...';./test.sh < /usr/local/etc/ssl/cert.pem | tail -5
FNMT-RCM
FNMT-RCM
ACCV
Actalis S.p.A./03358520967
AffirmTrust
...
The USERTRUST Network
The USERTRUST Network
"VeriSign, Inc."
"VeriSign, Inc."
XRamp Security Services Inc
-121 ---310406 -Когда X-сервер запускается с опцией -auth
, он создает файл сMIT-MAGIC-COOKIE-1
(паролем ), и только пользователи, знающие этот пароль, могут отображать свои окна в системе X Window.
Может быть более одногоMIT-MAGIC-COOKIE-1
(net login, ssh -X
,... ), но я думаю, что в вашем случае, если вы проверите эти файлы -, они будут иметь точно такое же содержание (cmp /root/.xauth1 /root/.xauth2
).
Однако, если вы запускаете другой X-сервер и используетеsudo
(или su
), новый пароль должен быть другим.
Таким образом, причина для разных файлов в том, что sudo
не знал, какой дисплей используется другими экземплярами, и он получает единственные пароли, которые ему нужны (и создает новый файл для их хранения ).
Я нашел уродливый обходной путь, который позволяет pkexec
работать правильно, дважды копируя файл cookie:
sudo xauth -f /root/.Xauthority add $(xauth list $DISPLAY) # copy the cookie for pkexec
sudo gedit # works thanks to what sudo is doing
pkexec env DISPLAY=$DISPLAY gedit # works thanks to the first line above
# Check out that I now have two files
sudo ls -la /root | grep auth
-rw------- 1 root root 57 Nov 11 11:22.xauth0XYhX3
-rw------- 1 root root 57 Nov 11 11:17.Xauthority
Я все еще ищу ответ на исходный вопрос (где на самом деле хранятся xauth
данные из временных файлов? ), что, надеюсь, позволит мне использовать один и тот же файл cookie для обеих команд sudo
и pkexec
.
Теперь все ясно, спасибо @user499944. Короче:
временные .xauthXXXXXX
файлы создаются с помощью pam_xauth
.
они создаются, только если установлено $DISPLAY
, что имеет место с sudo
, но не с pkexec
. Запуск pkexed env DISPLAY=$DISPLAY command
ничего не дает, потому что $DISPLAY
устанавливается только после аутентификации. Это видно из системных логов:
# after pkexec env DISPLAY=$DISPLAY xauth info
Nov 11 18:01:41 server pkexec[11650]: pam_xauth(polkit-1:session): user has no DISPLAY, doing nothing
Nov 11 18:01:41 server pkexec[11650]: user: Executing command [USER=root] [TTY=/dev/pts/3] [CWD=/home/user] [COMMAND=/usr/bin/env DISPLAY=localhost:10.0 xauth info]
# after sudo xauth info
Nov 11 18:04:12 server sudo[11666]: user : TTY=pts/3 ; PWD=/home/user ; USER=root ; COMMAND=/usr/bin/xauth info
# no message from pam_xauth about missing DISPLAY
Чтобы ответить на часть о , почемуpam_xauth
хранит каждый файл cookie в отдельном файле, есть две причины:
sudo
, удалив файл. В заключение :объем и время жизни.