[freebsd] test и пустые строки

[Irina Liakh]

Валентин, моё почтение за Ваше объяснение :)
Даже жалко скипать, но, наверное, надо.

On Tue, Nov 21, 2017 at 07:56:44AM +0200, Valentin Nechayev wrote:
> 
>  Tue, Nov 21, 2017 at 01:34:30, spell wrote about "Re: [freebsd] test и пустые строки": 
> 
> > > Я бы перефразировал: всплыло некорректное использование команды test.
> > 
> > О, это всё объясняет :) Спасибо.
> > Только ни разу не очевидно, что null string в случае "[ $str ]" допустим,
> > а в случае "[ -n $str ]" - нет. И тем более что оно молча fallback-ает в
> > treating an option as a regular string. 
> 
> А какой собственно у неё выход?

Согласна, но почему бы об этом не упомянуть в мане? Сэкономило бы много
времени не только мне. А лучше переписать usage syntax.
Вот эта строка:

     string        True if string is not the null string.

и работающая конструкция "[ ]" дают надежду на то, что аргументы могут
быть null'ами (это если не задумываться о реализации и наследии).
Поскольку в околошелльных кругах нет устоявшихся понятий
"null string", "zero string", "initialized variable" (нет же?), то
описание типа такого, кмк, было бы более прозрачным:

     [string]      True if string is specified and it's length is not zero.

> А теперь о случаях типа один аргумент, который проверяет на непустоту.
> Тут одновременно и наследие (в смысле legacy), и простой сокращённый
> случай - но это уже фактически та простота, которая не то хуже
> воровства, не то "просто" требует очень внимательного отношения к
> себе.

Эта "простота" мне вчера оказалась полезной :)
Кмк,

[ `somelongcommandline` ] && dosomething || doother

выглядит получше чем

[ -n "`somelongcommandline`" ] && dosomething || doother

> Как и вообще многое в шелле и вокруг. Test тут далеко не
> единственный пример. Возьмём grep. Мы можем десятки раз писать что-то
> типа "grep vasya /var/log/auth.log", но если шаблон приходит снаружи,
> мы обязаны написать:
> 
> grep -e "$pattern" "$file"
> 
> причём важны и -e - указать, что тут шаблон, и кавычки - чтобы шелл
> сохранил это одним аргументом, независимо от количества параметров в
> нём.

С grep всё очевидно и согласно процедурам word expansion и quote removal.

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

А что ещё связано с одноаргументным вариантом?

> Стандарт можете почитать сами тут:
> http://pubs.opengroup.org/onlinepubs/9699919799/utilities/test.html

Спасибо!

> а дальше посмотреть на то, как более дружественные шеллы (bash,
> zsh...) борются с последствиями этого. Как они расширяют сам test,
> как эмпирически пытаются разбирать сложные случаи, как вместо этого
> можно пользоваться конструкциями типа $((...)), и так далее.

С $(( )) связана отдельная боль...
За вот это:

$ echo $(( 010 ))
8

повбывавбы...

Ну что мешало добавить буковку "o" аналогично "x" в хексе?:

$ echo $(( 0x10 ))
16

Ведущие нули не так уж редко используются в числах, где подразумевается
именно десятичное число (для выравнивания сортировки, например).

> (Если бы мне дали это всё исправить, я бы сделал вариант с только
> префиксной записью всех вариантов (например, `= arg1 arg2' вместо `arg1
> = arg2'), начальную опцию для него, и загнал бы это кувалдой в стандарт.

Да-да..
Если бы мне дали всё исправить, я бы начала с того, что 0 - это true,
а 1 - false. (начиная с машинной логики, а не только в шеллах)