Блог

Кто-нибудь может объяснить результат приведенных выше тестов?

test1 и test2

Столбец пытается использовать языковой стандарт (т. е. UTF-8) для анализа входных данных, 0x99 сам по себе (без предшествования 0xc2 ) является недопустимой последовательностью Юникода.

Существует ошибка, из-за column которой не проверяется, является ли переданная строка -s допустимой строкой Юникода. column вызовы wcspbrk для поиска input_separator (т. е. $'x99' ) во входном потоке. Поскольку строка 0x99 является недопустимой последовательностью UTF-8, column вызывает wcspbrk в NULL качестве второго аргумента, и это вызывает ошибку seg.

column При анализе входных аргументов отсутствует проверка, она не проверяет , является ли возвращаемое значение mbs_to_wcs , которое вызывает mbstowcs проверку переданной строки -s NULL . Это можно было бы исправить с помощью чего-нибудь еще:

test3

Возможность -d paste и возможность -s column
укажите набор разделителей. paste -d "x99" Вставки просто x , и поскольку -s "x99" x они находятся в наборе разделителей, они просто разделяются по x символу.

test4

Также кажется, что столбцы преобразуют разбитые последовательности, например $'x99' , в x99 форму точно так же, как при чтении с входных данных. Из-за этого при paste вставке 0x99 байта вы можете установить -s x99 , потому column что преобразуете байт на входе в 4 байта x 9 9 и после этого работаете над входом, чтобы разбить его на столбцы.

Затем -s x99 последовательно обнаруживает 4 разделителя x 9 9 , так что вы получаете много пробелов.

В любом случае, решение в любом случае состоит в том, чтобы использовать байты меньше 128.

Я отправил вопрос util-linux на github https://github.com/karelzak/util-linux/issues/1425 и проблема, скорее всего, будет исправлена, и, похоже, в следующей column версии появится сообщение об ошибке, когда команде будет передана недопустимая последовательность UTF-8 -s .

Проблема была исправлена в вышестоящем репозитории util-linux (https://github.com/karelzak/util-linux/commit/9714331843ef3a6d9c10ff1d3bc5fcf53d44d930) и изменение будет доступно в следующем выпуске.

Кто-нибудь может объяснить результат приведенных выше тестов?

test1 и test2

Столбец пытается использовать языковой стандарт (т. е. UTF-8) для анализа входных данных, 0x99 сам по себе (без предшествования 0xc2 ) является недопустимой последовательностью Юникода.

Существует ошибка, из-за column которой не проверяется, является ли переданная строка -s допустимой строкой Юникода. column вызовы wcspbrk для поиска input_separator (т. е. $'x99' ) во входном потоке. Поскольку строка 0x99 является недопустимой последовательностью UTF-8, column вызывает wcspbrk в NULL качестве второго аргумента, и это вызывает ошибку seg.

column При анализе входных аргументов отсутствует проверка, она не проверяет , является ли возвращаемое значение mbs_to_wcs , которое вызывает mbstowcs проверку переданной строки -s NULL . Это можно было бы исправить с помощью чего-нибудь еще:

test3

Возможность -d paste и возможность -s column
укажите набор разделителей. paste -d "x99" Вставки просто x , и поскольку -s "x99" x они находятся в наборе разделителей, они просто разделяются по x символу.

test4

Также кажется, что столбцы преобразуют разбитые последовательности, например $'x99' , в x99 форму точно так же, как при чтении с входных данных. Из-за этого при paste вставке 0x99 байта вы можете установить -s x99 , потому column что преобразуете байт на входе в 4 байта x 9 9 и после этого работаете над входом, чтобы разбить его на столбцы.

Затем -s x99 последовательно обнаруживает 4 разделителя x 9 9 , так что вы получаете много пробелов.

В любом случае, решение в любом случае состоит в том, чтобы использовать байты меньше 128.

Я отправил вопрос util-linux на github https://github.com/karelzak/util-linux/issues/1425 и проблема, скорее всего, будет исправлена, и, похоже, в следующей column версии появится сообщение об ошибке, когда команде будет передана недопустимая последовательность UTF-8 -s .

Проблема была исправлена в вышестоящем репозитории util-linux (https://github.com/karelzak/util-linux/commit/9714331843ef3a6d9c10ff1d3bc5fcf53d44d930) и изменение будет доступно в следующем выпуске.

Кто-нибудь может объяснить результат приведенных выше тестов?

test1 и test2

Столбец пытается использовать языковой стандарт (т. е. UTF-8) для анализа входных данных, 0x99 сам по себе (без предшествования 0xc2 ) является недопустимой последовательностью Юникода.

Существует ошибка, из-за column которой не проверяется, является ли переданная строка -s допустимой строкой Юникода. column вызовы wcspbrk для поиска input_separator (т. е. $'x99' ) во входном потоке. Поскольку строка 0x99 является недопустимой последовательностью UTF-8, column вызывает wcspbrk в NULL качестве второго аргумента, и это вызывает ошибку seg.

column При анализе входных аргументов отсутствует проверка, она не проверяет , является ли возвращаемое значение mbs_to_wcs , которое вызывает mbstowcs проверку переданной строки -s NULL . Это можно было бы исправить с помощью чего-нибудь еще:

test3

Возможность -d paste и возможность -s column
укажите набор разделителей. paste -d "x99" Вставки просто x , и поскольку -s "x99" x они находятся в наборе разделителей, они просто разделяются по x символу.

test4

Также кажется, что столбцы преобразуют разбитые последовательности, например $'x99' , в x99 форму точно так же, как при чтении с входных данных. Из-за этого при paste вставке 0x99 байта вы можете установить -s x99 , потому column что преобразуете байт на входе в 4 байта x 9 9 и после этого работаете над входом, чтобы разбить его на столбцы.

Затем -s x99 последовательно обнаруживает 4 разделителя x 9 9 , так что вы получаете много пробелов.

В любом случае, решение в любом случае состоит в том, чтобы использовать байты меньше 128.

Я отправил вопрос util-linux на github https://github.com/karelzak/util-linux/issues/1425 и проблема, скорее всего, будет исправлена, и, похоже, в следующей column версии появится сообщение об ошибке, когда команде будет передана недопустимая последовательность UTF-8 -s .

Проблема была исправлена в вышестоящем репозитории util-linux (https://github.com/karelzak/util-linux/commit/9714331843ef3a6d9c10ff1d3bc5fcf53d44d930) и изменение будет доступно в следующем выпуске.

Кто-нибудь может объяснить результат приведенных выше тестов?

test1 и test2

Столбец пытается использовать языковой стандарт (т. е. UTF-8) для анализа входных данных, 0x99 сам по себе (без предшествования 0xc2 ) является недопустимой последовательностью Юникода.

Существует ошибка, из-за column которой не проверяется, является ли переданная строка -s допустимой строкой Юникода. column вызовы wcspbrk для поиска input_separator (т. е. $'x99' ) во входном потоке. Поскольку строка 0x99 является недопустимой последовательностью UTF-8, column вызывает wcspbrk в NULL качестве второго аргумента, и это вызывает ошибку seg.

column При анализе входных аргументов отсутствует проверка, она не проверяет , является ли возвращаемое значение mbs_to_wcs , которое вызывает mbstowcs проверку переданной строки -s NULL . Это можно было бы исправить с помощью чего-нибудь еще:

test3

Возможность -d paste и возможность -s column
укажите набор разделителей. paste -d "x99" Вставки просто x , и поскольку -s "x99" x они находятся в наборе разделителей, они просто разделяются по x символу.

test4

Также кажется, что столбцы преобразуют разбитые последовательности, например $'x99' , в x99 форму точно так же, как при чтении с входных данных. Из-за этого при paste вставке 0x99 байта вы можете установить -s x99 , потому column что преобразуете байт на входе в 4 байта x 9 9 и после этого работаете над входом, чтобы разбить его на столбцы.

Затем -s x99 последовательно обнаруживает 4 разделителя x 9 9 , так что вы получаете много пробелов.

В любом случае, решение в любом случае состоит в том, чтобы использовать байты меньше 128.

Я отправил вопрос util-linux на github https://github.com/karelzak/util-linux/issues/1425 и проблема, скорее всего, будет исправлена, и, похоже, в следующей column версии появится сообщение об ошибке, когда команде будет передана недопустимая последовательность UTF-8 -s .

Проблема была исправлена в вышестоящем репозитории util-linux (https://github.com/karelzak/util-linux/commit/9714331843ef3a6d9c10ff1d3bc5fcf53d44d930) и изменение будет доступно в следующем выпуске.

Кто-нибудь может объяснить результат приведенных выше тестов?

test1 и test2

Столбец пытается использовать языковой стандарт (т. е. UTF-8) для анализа входных данных, 0x99 сам по себе (без предшествования 0xc2 ) является недопустимой последовательностью Юникода.

Существует ошибка, из-за column которой не проверяется, является ли переданная строка -s допустимой строкой Юникода. column вызовы wcspbrk для поиска input_separator (т. е. $'x99' ) во входном потоке. Поскольку строка 0x99 является недопустимой последовательностью UTF-8, column вызывает wcspbrk в NULL качестве второго аргумента, и это вызывает ошибку seg.

column При анализе входных аргументов отсутствует проверка, она не проверяет , является ли возвращаемое значение mbs_to_wcs , которое вызывает mbstowcs проверку переданной строки -s NULL . Это можно было бы исправить с помощью чего-нибудь еще:

test3

Возможность -d paste и возможность -s column
укажите набор разделителей. paste -d "x99" Вставки просто x , и поскольку -s "x99" x они находятся в наборе разделителей, они просто разделяются по x символу.

test4

Также кажется, что столбцы преобразуют разбитые последовательности, например $'x99' , в x99 форму точно так же, как при чтении с входных данных. Из-за этого при paste вставке 0x99 байта вы можете установить -s x99 , потому column что преобразуете байт на входе в 4 байта x 9 9 и после этого работаете над входом, чтобы разбить его на столбцы.

Затем -s x99 последовательно обнаруживает 4 разделителя x 9 9 , так что вы получаете много пробелов.

В любом случае, решение в любом случае состоит в том, чтобы использовать байты меньше 128.

Я отправил вопрос util-linux на github https://github.com/karelzak/util-linux/issues/1425 и проблема, скорее всего, будет исправлена, и, похоже, в следующей column версии появится сообщение об ошибке, когда команде будет передана недопустимая последовательность UTF-8 -s .

Проблема была исправлена в вышестоящем репозитории util-linux (https://github.com/karelzak/util-linux/commit/9714331843ef3a6d9c10ff1d3bc5fcf53d44d930) и изменение будет доступно в следующем выпуске.

Кто-нибудь может объяснить результат приведенных выше тестов?

test1 и test2

Столбец пытается использовать языковой стандарт (т. е. UTF-8) для анализа входных данных, 0x99 сам по себе (без предшествования 0xc2 ) является недопустимой последовательностью Юникода.

Существует ошибка, из-за column которой не проверяется, является ли переданная строка -s допустимой строкой Юникода. column вызовы wcspbrk для поиска input_separator (т. е. $'x99' ) во входном потоке. Поскольку строка 0x99 является недопустимой последовательностью UTF-8, column вызывает wcspbrk в NULL качестве второго аргумента, и это вызывает ошибку seg.

column При анализе входных аргументов отсутствует проверка, она не проверяет , является ли возвращаемое значение mbs_to_wcs , которое вызывает mbstowcs проверку переданной строки -s NULL . Это можно было бы исправить с помощью чего-нибудь еще:

test3

Возможность -d paste и возможность -s column
укажите набор разделителей. paste -d "x99" Вставки просто x , и поскольку -s "x99" x они находятся в наборе разделителей, они просто разделяются по x символу.

test4

Также кажется, что столбцы преобразуют разбитые последовательности, например $'x99' , в x99 форму точно так же, как при чтении с входных данных. Из-за этого при paste вставке 0x99 байта вы можете установить -s x99 , потому column что преобразуете байт на входе в 4 байта x 9 9 и после этого работаете над входом, чтобы разбить его на столбцы.

Затем -s x99 последовательно обнаруживает 4 разделителя x 9 9 , так что вы получаете много пробелов.

В любом случае, решение в любом случае состоит в том, чтобы использовать байты меньше 128.

Я отправил вопрос util-linux на github https://github.com/karelzak/util-linux/issues/1425 и проблема, скорее всего, будет исправлена, и, похоже, в следующей column версии появится сообщение об ошибке, когда команде будет передана недопустимая последовательность UTF-8 -s .

Проблема была исправлена в вышестоящем репозитории util-linux (https://github.com/karelzak/util-linux/commit/9714331843ef3a6d9c10ff1d3bc5fcf53d44d930) и изменение будет доступно в следующем выпуске.

Кто-нибудь может объяснить результат приведенных выше тестов?

test1 и test2

Столбец пытается использовать языковой стандарт (т. е. UTF-8) для анализа входных данных, 0x99 сам по себе (без предшествования 0xc2 ) является недопустимой последовательностью Юникода.

Существует ошибка, из-за column которой не проверяется, является ли переданная строка -s допустимой строкой Юникода. column вызовы wcspbrk для поиска input_separator (т. е. $'x99' ) во входном потоке. Поскольку строка 0x99 является недопустимой последовательностью UTF-8, column вызывает wcspbrk в NULL качестве второго аргумента, и это вызывает ошибку seg.

column При анализе входных аргументов отсутствует проверка, она не проверяет , является ли возвращаемое значение mbs_to_wcs , которое вызывает mbstowcs проверку переданной строки -s NULL . Это можно было бы исправить с помощью чего-нибудь еще:

test3

Возможность -d paste и возможность -s column
укажите набор разделителей. paste -d "x99" Вставки просто x , и поскольку -s "x99" x они находятся в наборе разделителей, они просто разделяются по x символу.

test4

Также кажется, что столбцы преобразуют разбитые последовательности, например $'x99' , в x99 форму точно так же, как при чтении с входных данных. Из-за этого при paste вставке 0x99 байта вы можете установить -s x99 , потому column что преобразуете байт на входе в 4 байта x 9 9 и после этого работаете над входом, чтобы разбить его на столбцы.

Затем -s x99 последовательно обнаруживает 4 разделителя x 9 9 , так что вы получаете много пробелов.

В любом случае, решение в любом случае состоит в том, чтобы использовать байты меньше 128.

Я отправил вопрос util-linux на github https://github.com/karelzak/util-linux/issues/1425 и проблема, скорее всего, будет исправлена, и, похоже, в следующей column версии появится сообщение об ошибке, когда команде будет передана недопустимая последовательность UTF-8 -s .

Проблема была исправлена в вышестоящем репозитории util-linux (https://github.com/karelzak/util-linux/commit/9714331843ef3a6d9c10ff1d3bc5fcf53d44d930) и изменение будет доступно в следующем выпуске.

Кто-нибудь может объяснить результат приведенных выше тестов?

test1 и test2

Столбец пытается использовать языковой стандарт (т. е. UTF-8) для анализа входных данных, 0x99 сам по себе (без предшествования 0xc2 ) является недопустимой последовательностью Юникода.

Существует ошибка, из-за column которой не проверяется, является ли переданная строка -s допустимой строкой Юникода. column вызовы wcspbrk для поиска input_separator (т. е. $'x99' ) во входном потоке. Поскольку строка 0x99 является недопустимой последовательностью UTF-8, column вызывает wcspbrk в NULL качестве второго аргумента, и это вызывает ошибку seg.

column При анализе входных аргументов отсутствует проверка, она не проверяет , является ли возвращаемое значение mbs_to_wcs , которое вызывает mbstowcs проверку переданной строки -s NULL . Это можно было бы исправить с помощью чего-нибудь еще:

test3

Возможность -d paste и возможность -s column
укажите набор разделителей. paste -d "x99" Вставки просто x , и поскольку -s "x99" x они находятся в наборе разделителей, они просто разделяются по x символу.

test4

Также кажется, что столбцы преобразуют разбитые последовательности, например $'x99' , в x99 форму точно так же, как при чтении с входных данных. Из-за этого при paste вставке 0x99 байта вы можете установить -s x99 , потому column что преобразуете байт на входе в 4 байта x 9 9 и после этого работаете над входом, чтобы разбить его на столбцы.

Затем -s x99 последовательно обнаруживает 4 разделителя x 9 9 , так что вы получаете много пробелов.

В любом случае, решение в любом случае состоит в том, чтобы использовать байты меньше 128.

Я отправил вопрос util-linux на github https://github.com/karelzak/util-linux/issues/1425 и проблема, скорее всего, будет исправлена, и, похоже, в следующей column версии появится сообщение об ошибке, когда команде будет передана недопустимая последовательность UTF-8 -s .

Проблема была исправлена в вышестоящем репозитории util-linux (https://github.com/karelzak/util-linux/commit/9714331843ef3a6d9c10ff1d3bc5fcf53d44d930) и изменение будет доступно в следующем выпуске.

Кто-нибудь может объяснить результат приведенных выше тестов?

test1 и test2

Столбец пытается использовать языковой стандарт (т. е. UTF-8) для анализа входных данных, 0x99 сам по себе (без предшествования 0xc2 ) является недопустимой последовательностью Юникода.

Существует ошибка, из-за column которой не проверяется, является ли переданная строка -s допустимой строкой Юникода. column вызовы wcspbrk для поиска input_separator (т. е. $'x99' ) во входном потоке. Поскольку строка 0x99 является недопустимой последовательностью UTF-8, column вызывает wcspbrk в NULL качестве второго аргумента, и это вызывает ошибку seg.

column При анализе входных аргументов отсутствует проверка, она не проверяет , является ли возвращаемое значение mbs_to_wcs , которое вызывает mbstowcs проверку переданной строки -s NULL . Это можно было бы исправить с помощью чего-нибудь еще:

test3

Возможность -d paste и возможность -s column
укажите набор разделителей. paste -d "x99" Вставки просто x , и поскольку -s "x99" x они находятся в наборе разделителей, они просто разделяются по x символу.

test4

Также кажется, что столбцы преобразуют разбитые последовательности, например $'x99' , в x99 форму точно так же, как при чтении с входных данных. Из-за этого при paste вставке 0x99 байта вы можете установить -s x99 , потому column что преобразуете байт на входе в 4 байта x 9 9 и после этого работаете над входом, чтобы разбить его на столбцы.

Затем -s x99 последовательно обнаруживает 4 разделителя x 9 9 , так что вы получаете много пробелов.

В любом случае, решение в любом случае состоит в том, чтобы использовать байты меньше 128.

Я отправил вопрос util-linux на github https://github.com/karelzak/util-linux/issues/1425 и проблема, скорее всего, будет исправлена, и, похоже, в следующей column версии появится сообщение об ошибке, когда команде будет передана недопустимая последовательность UTF-8 -s .

Проблема была исправлена в вышестоящем репозитории util-linux (https://github.com/karelzak/util-linux/commit/9714331843ef3a6d9c10ff1d3bc5fcf53d44d930) и изменение будет доступно в следующем выпуске.

Кто-нибудь может объяснить результат приведенных выше тестов?

test1 и test2

Столбец пытается использовать языковой стандарт (т. е. UTF-8) для анализа входных данных, 0x99 сам по себе (без предшествования 0xc2 ) является недопустимой последовательностью Юникода.

Существует ошибка, из-за column которой не проверяется, является ли переданная строка -s допустимой строкой Юникода. column вызовы wcspbrk для поиска input_separator (т. е. $'x99' ) во входном потоке. Поскольку строка 0x99 является недопустимой последовательностью UTF-8, column вызывает wcspbrk в NULL качестве второго аргумента, и это вызывает ошибку seg.

column При анализе входных аргументов отсутствует проверка, она не проверяет , является ли возвращаемое значение mbs_to_wcs , которое вызывает mbstowcs проверку переданной строки -s NULL . Это можно было бы исправить с помощью чего-нибудь еще:

test3

Возможность -d paste и возможность -s column
укажите набор разделителей. paste -d "x99" Вставки просто x , и поскольку -s "x99" x они находятся в наборе разделителей, они просто разделяются по x символу.

test4

Также кажется, что столбцы преобразуют разбитые последовательности, например $'x99' , в x99 форму точно так же, как при чтении с входных данных. Из-за этого при paste вставке 0x99 байта вы можете установить -s x99 , потому column что преобразуете байт на входе в 4 байта x 9 9 и после этого работаете над входом, чтобы разбить его на столбцы.

Затем -s x99 последовательно обнаруживает 4 разделителя x 9 9 , так что вы получаете много пробелов.

В любом случае, решение в любом случае состоит в том, чтобы использовать байты меньше 128.

Я отправил вопрос util-linux на github https://github.com/karelzak/util-linux/issues/1425 и проблема, скорее всего, будет исправлена, и, похоже, в следующей column версии появится сообщение об ошибке, когда команде будет передана недопустимая последовательность UTF-8 -s .

Проблема была исправлена в вышестоящем репозитории util-linux (https://github.com/karelzak/util-linux/commit/9714331843ef3a6d9c10ff1d3bc5fcf53d44d930) и изменение будет доступно в следующем выпуске.

Кто-нибудь может объяснить результат приведенных выше тестов?

test1 и test2

Столбец пытается использовать языковой стандарт (т. е. UTF-8) для анализа входных данных, 0x99 сам по себе (без предшествования 0xc2 ) является недопустимой последовательностью Юникода.

Существует ошибка, из-за column которой не проверяется, является ли переданная строка -s допустимой строкой Юникода. column вызовы wcspbrk для поиска input_separator (т. е. $'x99' ) во входном потоке. Поскольку строка 0x99 является недопустимой последовательностью UTF-8, column вызывает wcspbrk в NULL качестве второго аргумента, и это вызывает ошибку seg.

column При анализе входных аргументов отсутствует проверка, она не проверяет , является ли возвращаемое значение mbs_to_wcs , которое вызывает mbstowcs проверку переданной строки -s NULL . Это можно было бы исправить с помощью чего-нибудь еще:

test3

Возможность -d paste и возможность -s column
укажите набор разделителей. paste -d "x99" Вставки просто x , и поскольку -s "x99" x они находятся в наборе разделителей, они просто разделяются по x символу.

test4

Также кажется, что столбцы преобразуют разбитые последовательности, например $'x99' , в x99 форму точно так же, как при чтении с входных данных. Из-за этого при paste вставке 0x99 байта вы можете установить -s x99 , потому column что преобразуете байт на входе в 4 байта x 9 9 и после этого работаете над входом, чтобы разбить его на столбцы.

Затем -s x99 последовательно обнаруживает 4 разделителя x 9 9 , так что вы получаете много пробелов.

В любом случае, решение в любом случае состоит в том, чтобы использовать байты меньше 128.

Я отправил вопрос util-linux на github https://github.com/karelzak/util-linux/issues/1425 и проблема, скорее всего, будет исправлена, и, похоже, в следующей column версии появится сообщение об ошибке, когда команде будет передана недопустимая последовательность UTF-8 -s .

Проблема была исправлена в вышестоящем репозитории util-linux (https://github.com/karelzak/util-linux/commit/9714331843ef3a6d9c10ff1d3bc5fcf53d44d930) и изменение будет доступно в следующем выпуске.

Кто-нибудь может объяснить результат приведенных выше тестов?

test1 и test2

Столбец пытается использовать языковой стандарт (т. е. UTF-8) для анализа входных данных, 0x99 сам по себе (без предшествования 0xc2 ) является недопустимой последовательностью Юникода.

Существует ошибка, из-за column которой не проверяется, является ли переданная строка -s допустимой строкой Юникода. column вызовы wcspbrk для поиска input_separator (т. е. $'x99' ) во входном потоке. Поскольку строка 0x99 является недопустимой последовательностью UTF-8, column вызывает wcspbrk в NULL качестве второго аргумента, и это вызывает ошибку seg.

column При анализе входных аргументов отсутствует проверка, она не проверяет , является ли возвращаемое значение mbs_to_wcs , которое вызывает mbstowcs проверку переданной строки -s NULL . Это можно было бы исправить с помощью чего-нибудь еще:

test3

Возможность -d paste и возможность -s column
укажите набор разделителей. paste -d "x99" Вставки просто x , и поскольку -s "x99" x они находятся в наборе разделителей, они просто разделяются по x символу.

test4

Также кажется, что столбцы преобразуют разбитые последовательности, например $'x99' , в x99 форму точно так же, как при чтении с входных данных. Из-за этого при paste вставке 0x99 байта вы можете установить -s x99 , потому column что преобразуете байт на входе в 4 байта x 9 9 и после этого работаете над входом, чтобы разбить его на столбцы.

Затем -s x99 последовательно обнаруживает 4 разделителя x 9 9 , так что вы получаете много пробелов.

В любом случае, решение в любом случае состоит в том, чтобы использовать байты меньше 128.

Я отправил вопрос util-linux на github https://github.com/karelzak/util-linux/issues/1425 и проблема, скорее всего, будет исправлена, и, похоже, в следующей column версии появится сообщение об ошибке, когда команде будет передана недопустимая последовательность UTF-8 -s .

Проблема была исправлена в вышестоящем репозитории util-linux (https://github.com/karelzak/util-linux/commit/9714331843ef3a6d9c10ff1d3bc5fcf53d44d930) и изменение будет доступно в следующем выпуске.

Кто-нибудь может объяснить результат приведенных выше тестов?

test1 и test2

Столбец пытается использовать языковой стандарт (т. е. UTF-8) для анализа входных данных, 0x99 сам по себе (без предшествования 0xc2 ) является недопустимой последовательностью Юникода.

Существует ошибка, из-за column которой не проверяется, является ли переданная строка -s допустимой строкой Юникода. column вызовы wcspbrk для поиска input_separator (т. е. $'x99' ) во входном потоке. Поскольку строка 0x99 является недопустимой последовательностью UTF-8, column вызывает wcspbrk в NULL качестве второго аргумента, и это вызывает ошибку seg.

column При анализе входных аргументов отсутствует проверка, она не проверяет , является ли возвращаемое значение mbs_to_wcs , которое вызывает mbstowcs проверку переданной строки -s NULL . Это можно было бы исправить с помощью чего-нибудь еще:

test3

Возможность -d paste и возможность -s column
укажите набор разделителей. paste -d "x99" Вставки просто x , и поскольку -s "x99" x они находятся в наборе разделителей, они просто разделяются по x символу.

test4

Также кажется, что столбцы преобразуют разбитые последовательности, например $'x99' , в x99 форму точно так же, как при чтении с входных данных. Из-за этого при paste вставке 0x99 байта вы можете установить -s x99 , потому column что преобразуете байт на входе в 4 байта x 9 9 и после этого работаете над входом, чтобы разбить его на столбцы.

Затем -s x99 последовательно обнаруживает 4 разделителя x 9 9 , так что вы получаете много пробелов.

В любом случае, решение в любом случае состоит в том, чтобы использовать байты меньше 128.

Я отправил вопрос util-linux на github https://github.com/karelzak/util-linux/issues/1425 и проблема, скорее всего, будет исправлена, и, похоже, в следующей column версии появится сообщение об ошибке, когда команде будет передана недопустимая последовательность UTF-8 -s .

Проблема была исправлена в вышестоящем репозитории util-linux (https://github.com/karelzak/util-linux/commit/9714331843ef3a6d9c10ff1d3bc5fcf53d44d930) и изменение будет доступно в следующем выпуске.

Кто-нибудь может объяснить результат приведенных выше тестов?

test1 и test2

Столбец пытается использовать языковой стандарт (т. е. UTF-8) для анализа входных данных, 0x99 сам по себе (без предшествования 0xc2 ) является недопустимой последовательностью Юникода.

Существует ошибка, из-за column которой не проверяется, является ли переданная строка -s допустимой строкой Юникода. column вызовы wcspbrk для поиска input_separator (т. е. $'x99' ) во входном потоке. Поскольку строка 0x99 является недопустимой последовательностью UTF-8, column вызывает wcspbrk в NULL качестве второго аргумента, и это вызывает ошибку seg.

column При анализе входных аргументов отсутствует проверка, она не проверяет , является ли возвращаемое значение mbs_to_wcs , которое вызывает mbstowcs проверку переданной строки -s NULL . Это можно было бы исправить с помощью чего-нибудь еще:

test3

Возможность -d paste и возможность -s column
укажите набор разделителей. paste -d "x99" Вставки просто x , и поскольку -s "x99" x они находятся в наборе разделителей, они просто разделяются по x символу.

test4

Также кажется, что столбцы преобразуют разбитые последовательности, например $'x99' , в x99 форму точно так же, как при чтении с входных данных. Из-за этого при paste вставке 0x99 байта вы можете установить -s x99 , потому column что преобразуете байт на входе в 4 байта x 9 9 и после этого работаете над входом, чтобы разбить его на столбцы.

Затем -s x99 последовательно обнаруживает 4 разделителя x 9 9 , так что вы получаете много пробелов.

В любом случае, решение в любом случае состоит в том, чтобы использовать байты меньше 128.

Я отправил вопрос util-linux на github https://github.com/karelzak/util-linux/issues/1425 и проблема, скорее всего, будет исправлена, и, похоже, в следующей column версии появится сообщение об ошибке, когда команде будет передана недопустимая последовательность UTF-8 -s .

Проблема была исправлена в вышестоящем репозитории util-linux (https://github.com/karelzak/util-linux/commit/9714331843ef3a6d9c10ff1d3bc5fcf53d44d930) и изменение будет доступно в следующем выпуске.

Кто-нибудь может объяснить результат приведенных выше тестов?

test1 и test2

Столбец пытается использовать языковой стандарт (т. е. UTF-8) для анализа входных данных, 0x99 сам по себе (без предшествования 0xc2 ) является недопустимой последовательностью Юникода.

Существует ошибка, из-за column которой не проверяется, является ли переданная строка -s допустимой строкой Юникода. column вызовы wcspbrk для поиска input_separator (т. е. $'x99' ) во входном потоке. Поскольку строка 0x99 является недопустимой последовательностью UTF-8, column вызывает wcspbrk в NULL качестве второго аргумента, и это вызывает ошибку seg.

column При анализе входных аргументов отсутствует проверка, она не проверяет , является ли возвращаемое значение mbs_to_wcs , которое вызывает mbstowcs проверку переданной строки -s NULL . Это можно было бы исправить с помощью чего-нибудь еще:

test3

Возможность -d paste и возможность -s column
укажите набор разделителей. paste -d "x99" Вставки просто x , и поскольку -s "x99" x они находятся в наборе разделителей, они просто разделяются по x символу.

test4

Также кажется, что столбцы преобразуют разбитые последовательности, например $'x99' , в x99 форму точно так же, как при чтении с входных данных. Из-за этого при paste вставке 0x99 байта вы можете установить -s x99 , потому column что преобразуете байт на входе в 4 байта x 9 9 и после этого работаете над входом, чтобы разбить его на столбцы.

Затем -s x99 последовательно обнаруживает 4 разделителя x 9 9 , так что вы получаете много пробелов.

В любом случае, решение в любом случае состоит в том, чтобы использовать байты меньше 128.

Я отправил вопрос util-linux на github https://github.com/karelzak/util-linux/issues/1425 и проблема, скорее всего, будет исправлена, и, похоже, в следующей column версии появится сообщение об ошибке, когда команде будет передана недопустимая последовательность UTF-8 -s .

Проблема была исправлена в вышестоящем репозитории util-linux (https://github.com/karelzak/util-linux/commit/9714331843ef3a6d9c10ff1d3bc5fcf53d44d930) и изменение будет доступно в следующем выпуске.

Кто-нибудь может объяснить результат приведенных выше тестов?

test1 и test2

Столбец пытается использовать языковой стандарт (т. е. UTF-8) для анализа входных данных, 0x99 сам по себе (без предшествования 0xc2 ) является недопустимой последовательностью Юникода.

Существует ошибка, из-за column которой не проверяется, является ли переданная строка -s допустимой строкой Юникода. column вызовы wcspbrk для поиска input_separator (т. е. $'x99' ) во входном потоке. Поскольку строка 0x99 является недопустимой последовательностью UTF-8, column вызывает wcspbrk в NULL качестве второго аргумента, и это вызывает ошибку seg.

column При анализе входных аргументов отсутствует проверка, она не проверяет , является ли возвращаемое значение mbs_to_wcs , которое вызывает mbstowcs проверку переданной строки -s NULL . Это можно было бы исправить с помощью чего-нибудь еще:

test3

Возможность -d paste и возможность -s column
укажите набор разделителей. paste -d "x99" Вставки просто x , и поскольку -s "x99" x они находятся в наборе разделителей, они просто разделяются по x символу.

test4

Также кажется, что столбцы преобразуют разбитые последовательности, например $'x99' , в x99 форму точно так же, как при чтении с входных данных. Из-за этого при paste вставке 0x99 байта вы можете установить -s x99 , потому column что преобразуете байт на входе в 4 байта x 9 9 и после этого работаете над входом, чтобы разбить его на столбцы.

Затем -s x99 последовательно обнаруживает 4 разделителя x 9 9 , так что вы получаете много пробелов.

В любом случае, решение в любом случае состоит в том, чтобы использовать байты меньше 128.

Я отправил вопрос util-linux на github https://github.com/karelzak/util-linux/issues/1425 и проблема, скорее всего, будет исправлена, и, похоже, в следующей column версии появится сообщение об ошибке, когда команде будет передана недопустимая последовательность UTF-8 -s .

Проблема была исправлена в вышестоящем репозитории util-linux (https://github.com/karelzak/util-linux/commit/9714331843ef3a6d9c10ff1d3bc5fcf53d44d930) и изменение будет доступно в следующем выпуске.

Кто-нибудь может объяснить результат приведенных выше тестов?

test1 и test2

Столбец пытается использовать языковой стандарт (т. е. UTF-8) для анализа входных данных, 0x99 сам по себе (без предшествования 0xc2 ) является недопустимой последовательностью Юникода.

Существует ошибка, из-за column которой не проверяется, является ли переданная строка -s допустимой строкой Юникода. column вызовы wcspbrk для поиска input_separator (т. е. $'x99' ) во входном потоке. Поскольку строка 0x99 является недопустимой последовательностью UTF-8, column вызывает wcspbrk в NULL качестве второго аргумента, и это вызывает ошибку seg.

column При анализе входных аргументов отсутствует проверка, она не проверяет , является ли возвращаемое значение mbs_to_wcs , которое вызывает mbstowcs проверку переданной строки -s NULL . Это можно было бы исправить с помощью чего-нибудь еще:

test3

Возможность -d paste и возможность -s column
укажите набор разделителей. paste -d "x99" Вставки просто x , и поскольку -s "x99" x они находятся в наборе разделителей, они просто разделяются по x символу.

test4

Также кажется, что столбцы преобразуют разбитые последовательности, например $'x99' , в x99 форму точно так же, как при чтении с входных данных. Из-за этого при paste вставке 0x99 байта вы можете установить -s x99 , потому column что преобразуете байт на входе в 4 байта x 9 9 и после этого работаете над входом, чтобы разбить его на столбцы.

Затем -s x99 последовательно обнаруживает 4 разделителя x 9 9 , так что вы получаете много пробелов.

В любом случае, решение в любом случае состоит в том, чтобы использовать байты меньше 128.

Я отправил вопрос util-linux на github https://github.com/karelzak/util-linux/issues/1425 и проблема, скорее всего, будет исправлена, и, похоже, в следующей column версии появится сообщение об ошибке, когда команде будет передана недопустимая последовательность UTF-8 -s .

Проблема была исправлена в вышестоящем репозитории util-linux (https://github.com/karelzak/util-linux/commit/9714331843ef3a6d9c10ff1d3bc5fcf53d44d930) и изменение будет доступно в следующем выпуске.

Кто-нибудь может объяснить результат приведенных выше тестов?

test1 и test2

Столбец пытается использовать языковой стандарт (т. е. UTF-8) для анализа входных данных, 0x99 сам по себе (без предшествования 0xc2 ) является недопустимой последовательностью Юникода.

Существует ошибка, из-за column которой не проверяется, является ли переданная строка -s допустимой строкой Юникода. column вызовы wcspbrk для поиска input_separator (т. е. $'x99' ) во входном потоке. Поскольку строка 0x99 является недопустимой последовательностью UTF-8, column вызывает wcspbrk в NULL качестве второго аргумента, и это вызывает ошибку seg.

column При анализе входных аргументов отсутствует проверка, она не проверяет , является ли возвращаемое значение mbs_to_wcs , которое вызывает mbstowcs проверку переданной строки -s NULL . Это можно было бы исправить с помощью чего-нибудь еще:

test3

Возможность -d paste и возможность -s column
укажите набор разделителей. paste -d "x99" Вставки просто x , и поскольку -s "x99" x они находятся в наборе разделителей, они просто разделяются по x символу.

test4

Также кажется, что столбцы преобразуют разбитые последовательности, например $'x99' , в x99 форму точно так же, как при чтении с входных данных. Из-за этого при paste вставке 0x99 байта вы можете установить -s x99 , потому column что преобразуете байт на входе в 4 байта x 9 9 и после этого работаете над входом, чтобы разбить его на столбцы.

Затем -s x99 последовательно обнаруживает 4 разделителя x 9 9 , так что вы получаете много пробелов.

В любом случае, решение в любом случае состоит в том, чтобы использовать байты меньше 128.

Я отправил вопрос util-linux на github https://github.com/karelzak/util-linux/issues/1425 и проблема, скорее всего, будет исправлена, и, похоже, в следующей column версии появится сообщение об ошибке, когда команде будет передана недопустимая последовательность UTF-8 -s .

Проблема была исправлена в вышестоящем репозитории util-linux (https://github.com/karelzak/util-linux/commit/9714331843ef3a6d9c10ff1d3bc5fcf53d44d930) и изменение будет доступно в следующем выпуске.

Кто-нибудь может объяснить результат приведенных выше тестов?

test1 и test2

Столбец пытается использовать языковой стандарт (т. е. UTF-8) для анализа входных данных, 0x99 сам по себе (без предшествования 0xc2 ) является недопустимой последовательностью Юникода.

Существует ошибка, из-за column которой не проверяется, является ли переданная строка -s допустимой строкой Юникода. column вызовы wcspbrk для поиска input_separator (т. е. $'x99' ) во входном потоке. Поскольку строка 0x99 является недопустимой последовательностью UTF-8, column вызывает wcspbrk в NULL качестве второго аргумента, и это вызывает ошибку seg.

column При анализе входных аргументов отсутствует проверка, она не проверяет , является ли возвращаемое значение mbs_to_wcs , которое вызывает mbstowcs проверку переданной строки -s NULL . Это можно было бы исправить с помощью чего-нибудь еще:

test3

Возможность -d paste и возможность -s column
укажите набор разделителей. paste -d "x99" Вставки просто x , и поскольку -s "x99" x они находятся в наборе разделителей, они просто разделяются по x символу.

test4

Также кажется, что столбцы преобразуют разбитые последовательности, например $'x99' , в x99 форму точно так же, как при чтении с входных данных. Из-за этого при paste вставке 0x99 байта вы можете установить -s x99 , потому column что преобразуете байт на входе в 4 байта x 9 9 и после этого работаете над входом, чтобы разбить его на столбцы.

Затем -s x99 последовательно обнаруживает 4 разделителя x 9 9 , так что вы получаете много пробелов.

В любом случае, решение в любом случае состоит в том, чтобы использовать байты меньше 128.

Я отправил вопрос util-linux на github https://github.com/karelzak/util-linux/issues/1425 и проблема, скорее всего, будет исправлена, и, похоже, в следующей column версии появится сообщение об ошибке, когда команде будет передана недопустимая последовательность UTF-8 -s .

Проблема была исправлена в вышестоящем репозитории util-linux (https://github.com/karelzak/util-linux/commit/9714331843ef3a6d9c10ff1d3bc5fcf53d44d930) и изменение будет доступно в следующем выпуске.

Кто-нибудь может объяснить результат приведенных выше тестов?

test1 и test2

Столбец пытается использовать языковой стандарт (т. е. UTF-8) для анализа входных данных, 0x99 сам по себе (без предшествования 0xc2 ) является недопустимой последовательностью Юникода.

Существует ошибка, из-за column которой не проверяется, является ли переданная строка -s допустимой строкой Юникода. column вызовы wcspbrk для поиска input_separator (т. е. $'x99' ) во входном потоке. Поскольку строка 0x99 является недопустимой последовательностью UTF-8, column вызывает wcspbrk в NULL качестве второго аргумента, и это вызывает ошибку seg.

column При анализе входных аргументов отсутствует проверка, она не проверяет , является ли возвращаемое значение mbs_to_wcs , которое вызывает mbstowcs проверку переданной строки -s NULL . Это можно было бы исправить с помощью чего-нибудь еще:

test3

Возможность -d paste и возможность -s column
укажите набор разделителей. paste -d "x99" Вставки просто x , и поскольку -s "x99" x они находятся в наборе разделителей, они просто разделяются по x символу.

test4

Также кажется, что столбцы преобразуют разбитые последовательности, например $'x99' , в x99 форму точно так же, как при чтении с входных данных. Из-за этого при paste вставке 0x99 байта вы можете установить -s x99 , потому column что преобразуете байт на входе в 4 байта x 9 9 и после этого работаете над входом, чтобы разбить его на столбцы.

Затем -s x99 последовательно обнаруживает 4 разделителя x 9 9 , так что вы получаете много пробелов.

В любом случае, решение в любом случае состоит в том, чтобы использовать байты меньше 128.

Я отправил вопрос util-linux на github https://github.com/karelzak/util-linux/issues/1425 и проблема, скорее всего, будет исправлена, и, похоже, в следующей column версии появится сообщение об ошибке, когда команде будет передана недопустимая последовательность UTF-8 -s .

Проблема была исправлена в вышестоящем репозитории util-linux (https://github.com/karelzak/util-linux/commit/9714331843ef3a6d9c10ff1d3bc5fcf53d44d930) и изменение будет доступно в следующем выпуске.

Кто-нибудь может объяснить результат приведенных выше тестов?

test1 и test2

Столбец пытается использовать языковой стандарт (т. е. UTF-8) для анализа входных данных, 0x99 сам по себе (без предшествования 0xc2 ) является недопустимой последовательностью Юникода.

Существует ошибка, из-за column которой не проверяется, является ли переданная строка -s допустимой строкой Юникода. column вызовы wcspbrk для поиска input_separator (т. е. $'x99' ) во входном потоке. Поскольку строка 0x99 является недопустимой последовательностью UTF-8, column вызывает wcspbrk в NULL качестве второго аргумента, и это вызывает ошибку seg.

column При анализе входных аргументов отсутствует проверка, она не проверяет , является ли возвращаемое значение mbs_to_wcs , которое вызывает mbstowcs проверку переданной строки -s NULL . Это можно было бы исправить с помощью чего-нибудь еще:

test3

Возможность -d paste и возможность -s column
укажите набор разделителей. paste -d "x99" Вставки просто x , и поскольку -s "x99" x они находятся в наборе разделителей, они просто разделяются по x символу.

test4

Также кажется, что столбцы преобразуют разбитые последовательности, например $'x99' , в x99 форму точно так же, как при чтении с входных данных. Из-за этого при paste вставке 0x99 байта вы можете установить -s x99 , потому column что преобразуете байт на входе в 4 байта x 9 9 и после этого работаете над входом, чтобы разбить его на столбцы.

Затем -s x99 последовательно обнаруживает 4 разделителя x 9 9 , так что вы получаете много пробелов.

В любом случае, решение в любом случае состоит в том, чтобы использовать байты меньше 128.

Я отправил вопрос util-linux на github https://github.com/karelzak/util-linux/issues/1425 и проблема, скорее всего, будет исправлена, и, похоже, в следующей column версии появится сообщение об ошибке, когда команде будет передана недопустимая последовательность UTF-8 -s .

Проблема была исправлена в вышестоящем репозитории util-linux (https://github.com/karelzak/util-linux/commit/9714331843ef3a6d9c10ff1d3bc5fcf53d44d930) и изменение будет доступно в следующем выпуске.

Кто-нибудь может объяснить результат приведенных выше тестов?

test1 и test2

Столбец пытается использовать языковой стандарт (т. е. UTF-8) для анализа входных данных, 0x99 сам по себе (без предшествования 0xc2 ) является недопустимой последовательностью Юникода.

Существует ошибка, из-за column которой не проверяется, является ли переданная строка -s допустимой строкой Юникода. column вызовы wcspbrk для поиска input_separator (т. е. $'x99' ) во входном потоке. Поскольку строка 0x99 является недопустимой последовательностью UTF-8, column вызывает wcspbrk в NULL качестве второго аргумента, и это вызывает ошибку seg.

column При анализе входных аргументов отсутствует проверка, она не проверяет , является ли возвращаемое значение mbs_to_wcs , которое вызывает mbstowcs проверку переданной строки -s NULL . Это можно было бы исправить с помощью чего-нибудь еще:

test3

Возможность -d paste и возможность -s column
укажите набор разделителей. paste -d "x99" Вставки просто x , и поскольку -s "x99" x они находятся в наборе разделителей, они просто разделяются по x символу.

test4

Также кажется, что столбцы преобразуют разбитые последовательности, например $'x99' , в x99 форму точно так же, как при чтении с входных данных. Из-за этого при paste вставке 0x99 байта вы можете установить -s x99 , потому column что преобразуете байт на входе в 4 байта x 9 9 и после этого работаете над входом, чтобы разбить его на столбцы.

Затем -s x99 последовательно обнаруживает 4 разделителя x 9 9 , так что вы получаете много пробелов.

В любом случае, решение в любом случае состоит в том, чтобы использовать байты меньше 128.

Я отправил вопрос util-linux на github https://github.com/karelzak/util-linux/issues/1425 и проблема, скорее всего, будет исправлена, и, похоже, в следующей column версии появится сообщение об ошибке, когда команде будет передана недопустимая последовательность UTF-8 -s .

Проблема была исправлена в вышестоящем репозитории util-linux (https://github.com/karelzak/util-linux/commit/9714331843ef3a6d9c10ff1d3bc5fcf53d44d930) и изменение будет доступно в следующем выпуске.

Проблема была исправлена в вышестоящем репозитории util-linux (https://github.com/karelzak/util-linux/commit/9714331843ef3a6d9c10ff1d3bc5fcf53d44d930) и изменение будет доступно в следующем выпуске.

Кто-нибудь может объяснить результат приведенных выше тестов?

test1 и test2

Столбец пытается использовать языковой стандарт (т. е. UTF-8) для анализа входных данных, 0x99 сам по себе (без предшествования 0xc2 ) является недопустимой последовательностью Юникода.

Существует ошибка, из-за column которой не проверяется, является ли переданная строка -s допустимой строкой Юникода. column вызовы wcspbrk для поиска input_separator (т. е. $'x99' ) во входном потоке. Поскольку строка 0x99 является недопустимой последовательностью UTF-8, column вызывает wcspbrk в NULL качестве второго аргумента, и это вызывает ошибку seg.

column При анализе входных аргументов отсутствует проверка, она не проверяет , является ли возвращаемое значение mbs_to_wcs , которое вызывает mbstowcs проверку переданной строки -s NULL . Это можно было бы исправить с помощью чего-нибудь еще:

test3

Возможность -d paste и возможность -s column
укажите набор разделителей. paste -d "x99" Вставки просто x , и поскольку -s "x99" x они находятся в наборе разделителей, они просто разделяются по x символу.

test4

Также кажется, что столбцы преобразуют разбитые последовательности, например $'x99' , в x99 форму точно так же, как при чтении с входных данных. Из-за этого при paste вставке 0x99 байта вы можете установить -s x99 , потому column что преобразуете байт на входе в 4 байта x 9 9 и после этого работаете над входом, чтобы разбить его на столбцы.

Затем -s x99 последовательно обнаруживает 4 разделителя x 9 9 , так что вы получаете много пробелов.

В любом случае, решение в любом случае состоит в том, чтобы использовать байты меньше 128.

Я отправил вопрос util-linux на github https://github.com/karelzak/util-linux/issues/1425 и проблема, скорее всего, будет исправлена, и, похоже, в следующей column версии появится сообщение об ошибке, когда команде будет передана недопустимая последовательность UTF-8 -s .

Проблема была исправлена в вышестоящем репозитории util-linux (https://github.com/karelzak/util-linux/commit/9714331843ef3a6d9c10ff1d3bc5fcf53d44d930) и изменение будет доступно в следующем выпуске.

Кто-нибудь может объяснить результат приведенных выше тестов?

test1 и test2

Столбец пытается использовать языковой стандарт (т. е. UTF-8) для анализа входных данных, 0x99 сам по себе (без предшествования 0xc2 ) является недопустимой последовательностью Юникода.

Существует ошибка, из-за column которой не проверяется, является ли переданная строка -s допустимой строкой Юникода. column вызовы wcspbrk для поиска input_separator (т. е. $'x99' ) во входном потоке. Поскольку строка 0x99 является недопустимой последовательностью UTF-8, column вызывает wcspbrk в NULL качестве второго аргумента, и это вызывает ошибку seg.

column При анализе входных аргументов отсутствует проверка, она не проверяет , является ли возвращаемое значение mbs_to_wcs , которое вызывает mbstowcs проверку переданной строки -s NULL . Это можно было бы исправить с помощью чего-нибудь еще:

test3

Возможность -d paste и возможность -s column
укажите набор разделителей. paste -d "x99" Вставки просто x , и поскольку -s "x99" x они находятся в наборе разделителей, они просто разделяются по x символу.

test4

Также кажется, что столбцы преобразуют разбитые последовательности, например $'x99' , в x99 форму точно так же, как при чтении с входных данных. Из-за этого при paste вставке 0x99 байта вы можете установить -s x99 , потому column что преобразуете байт на входе в 4 байта x 9 9 и после этого работаете над входом, чтобы разбить его на столбцы.

Затем -s x99 последовательно обнаруживает 4 разделителя x 9 9 , так что вы получаете много пробелов.

В любом случае, решение в любом случае состоит в том, чтобы использовать байты меньше 128.

Я отправил вопрос util-linux на github https://github.com/karelzak/util-linux/issues/1425 и проблема, скорее всего, будет исправлена, и, похоже, в следующей column версии появится сообщение об ошибке, когда команде будет передана недопустимая последовательность UTF-8 -s .

Проблема была исправлена в вышестоящем репозитории util-linux (https://github.com/karelzak/util-linux/commit/9714331843ef3a6d9c10ff1d3bc5fcf53d44d930) и изменение будет доступно в следующем выпуске.

Кто-нибудь может объяснить результат приведенных выше тестов?

test1 и test2

Столбец пытается использовать языковой стандарт (т. е. UTF-8) для анализа входных данных, 0x99 сам по себе (без предшествования 0xc2 ) является недопустимой последовательностью Юникода.

Существует ошибка, из-за column которой не проверяется, является ли переданная строка -s допустимой строкой Юникода. column вызовы wcspbrk для поиска input_separator (т. е. $'x99' ) во входном потоке. Поскольку строка 0x99 является недопустимой последовательностью UTF-8, column вызывает wcspbrk в NULL качестве второго аргумента, и это вызывает ошибку seg.

column При анализе входных аргументов отсутствует проверка, она не проверяет , является ли возвращаемое значение mbs_to_wcs , которое вызывает mbstowcs проверку переданной строки -s NULL . Это можно было бы исправить с помощью чего-нибудь еще:

test3

Возможность -d paste и возможность -s column
укажите набор разделителей. paste -d "x99" Вставки просто x , и поскольку -s "x99" x они находятся в наборе разделителей, они просто разделяются по x символу.

test4

Также кажется, что столбцы преобразуют разбитые последовательности, например $'x99' , в x99 форму точно так же, как при чтении с входных данных. Из-за этого при paste вставке 0x99 байта вы можете установить -s x99 , потому column что преобразуете байт на входе в 4 байта x 9 9 и после этого работаете над входом, чтобы разбить его на столбцы.

Затем -s x99 последовательно обнаруживает 4 разделителя x 9 9 , так что вы получаете много пробелов.

В любом случае, решение в любом случае состоит в том, чтобы использовать байты меньше 128.

Я отправил вопрос util-linux на github https://github.com/karelzak/util-linux/issues/1425 и проблема, скорее всего, будет исправлена, и, похоже, в следующей column версии появится сообщение об ошибке, когда команде будет передана недопустимая последовательность UTF-8 -s .

Проблема была исправлена в вышестоящем репозитории util-linux (https://github.com/karelzak/util-linux/commit/9714331843ef3a6d9c10ff1d3bc5fcf53d44d930) и изменение будет доступно в следующем выпуске.

Кто-нибудь может объяснить результат приведенных выше тестов?

test1 и test2

Столбец пытается использовать языковой стандарт (т. е. UTF-8) для анализа входных данных, 0x99 сам по себе (без предшествования 0xc2 ) является недопустимой последовательностью Юникода.

Существует ошибка, из-за column которой не проверяется, является ли переданная строка -s допустимой строкой Юникода. column вызовы wcspbrk для поиска input_separator (т. е. $'x99' ) во входном потоке. Поскольку строка 0x99 является недопустимой последовательностью UTF-8, column вызывает wcspbrk в NULL качестве второго аргумента, и это вызывает ошибку seg.

column При анализе входных аргументов отсутствует проверка, она не проверяет , является ли возвращаемое значение mbs_to_wcs , которое вызывает mbstowcs проверку переданной строки -s NULL . Это можно было бы исправить с помощью чего-нибудь еще:

test3

Возможность -d paste и возможность -s column
укажите набор разделителей. paste -d "x99" Вставки просто x , и поскольку -s "x99" x они находятся в наборе разделителей, они просто разделяются по x символу.

test4

Также кажется, что столбцы преобразуют разбитые последовательности, например $'x99' , в x99 форму точно так же, как при чтении с входных данных. Из-за этого при paste вставке 0x99 байта вы можете установить -s x99 , потому column что преобразуете байт на входе в 4 байта x 9 9 и после этого работаете над входом, чтобы разбить его на столбцы.

Затем -s x99 последовательно обнаруживает 4 разделителя x 9 9 , так что вы получаете много пробелов.

В любом случае, решение в любом случае состоит в том, чтобы использовать байты меньше 128.

Я отправил вопрос util-linux на github https://github.com/karelzak/util-linux/issues/1425 и проблема, скорее всего, будет исправлена, и, похоже, в следующей column версии появится сообщение об ошибке, когда команде будет передана недопустимая последовательность UTF-8 -s .

Проблема была исправлена в вышестоящем репозитории util-linux (https://github.com/karelzak/util-linux/commit/9714331843ef3a6d9c10ff1d3bc5fcf53d44d930) и изменение будет доступно в следующем выпуске.

Кто-нибудь может объяснить результат приведенных выше тестов?

test1 и test2

Столбец пытается использовать языковой стандарт (т. е. UTF-8) для анализа входных данных, 0x99 сам по себе (без предшествования 0xc2 ) является недопустимой последовательностью Юникода.

Существует ошибка, из-за column которой не проверяется, является ли переданная строка -s допустимой строкой Юникода. column вызовы wcspbrk для поиска input_separator (т. е. $'x99' ) во входном потоке. Поскольку строка 0x99 является недопустимой последовательностью UTF-8, column вызывает wcspbrk в NULL качестве второго аргумента, и это вызывает ошибку seg.

column При анализе входных аргументов отсутствует проверка, она не проверяет , является ли возвращаемое значение mbs_to_wcs , которое вызывает mbstowcs проверку переданной строки -s NULL . Это можно было бы исправить с помощью чего-нибудь еще:

test3

Возможность -d paste и возможность -s column
укажите набор разделителей. paste -d "x99" Вставки просто x , и поскольку -s "x99" x они находятся в наборе разделителей, они просто разделяются по x символу.

test4

Также кажется, что столбцы преобразуют разбитые последовательности, например $'x99' , в x99 форму точно так же, как при чтении с входных данных. Из-за этого при paste вставке 0x99 байта вы можете установить -s x99 , потому column что преобразуете байт на входе в 4 байта x 9 9 и после этого работаете над входом, чтобы разбить его на столбцы.

Затем -s x99 последовательно обнаруживает 4 разделителя x 9 9 , так что вы получаете много пробелов.

В любом случае, решение в любом случае состоит в том, чтобы использовать байты меньше 128.

Я отправил вопрос util-linux на github https://github.com/karelzak/util-linux/issues/1425 и проблема, скорее всего, будет исправлена, и, похоже, в следующей column версии появится сообщение об ошибке, когда команде будет передана недопустимая последовательность UTF-8 -s .

Проблема была исправлена в вышестоящем репозитории util-linux (https://github.com/karelzak/util-linux/commit/9714331843ef3a6d9c10ff1d3bc5fcf53d44d930) и изменение будет доступно в следующем выпуске.

Кто-нибудь может объяснить результат приведенных выше тестов?

test1 и test2

Столбец пытается использовать языковой стандарт (т. е. UTF-8) для анализа входных данных, 0x99 сам по себе (без предшествования 0xc2 ) является недопустимой последовательностью Юникода.

Существует ошибка, из-за column которой не проверяется, является ли переданная строка -s допустимой строкой Юникода. column вызовы wcspbrk для поиска input_separator (т. е. $'x99' ) во входном потоке. Поскольку строка 0x99 является недопустимой последовательностью UTF-8, column вызывает wcspbrk в NULL качестве второго аргумента, и это вызывает ошибку seg.

column При анализе входных аргументов отсутствует проверка, она не проверяет , является ли возвращаемое значение mbs_to_wcs , которое вызывает mbstowcs проверку переданной строки -s NULL . Это можно было бы исправить с помощью чего-нибудь еще:

test3

Возможность -d paste и возможность -s column
укажите набор разделителей. paste -d "x99" Вставки просто x , и поскольку -s "x99" x они находятся в наборе разделителей, они просто разделяются по x символу.

test4

Также кажется, что столбцы преобразуют разбитые последовательности, например $'x99' , в x99 форму точно так же, как при чтении с входных данных. Из-за этого при paste вставке 0x99 байта вы можете установить -s x99 , потому column что преобразуете байт на входе в 4 байта x 9 9 и после этого работаете над входом, чтобы разбить его на столбцы.

Затем -s x99 последовательно обнаруживает 4 разделителя x 9 9 , так что вы получаете много пробелов.

В любом случае, решение в любом случае состоит в том, чтобы использовать байты меньше 128.

Я отправил вопрос util-linux на github https://github.com/karelzak/util-linux/issues/1425 и проблема, скорее всего, будет исправлена, и, похоже, в следующей column версии появится сообщение об ошибке, когда команде будет передана недопустимая последовательность UTF-8 -s .

Проблема была исправлена в вышестоящем репозитории util-linux (https://github.com/karelzak/util-linux/commit/9714331843ef3a6d9c10ff1d3bc5fcf53d44d930) и изменение будет доступно в следующем выпуске.

Кто-нибудь может объяснить результат приведенных выше тестов?

test1 и test2

Столбец пытается использовать языковой стандарт (т. е. UTF-8) для анализа входных данных, 0x99 сам по себе (без предшествования 0xc2 ) является недопустимой последовательностью Юникода.

Существует ошибка, из-за column которой не проверяется, является ли переданная строка -s допустимой строкой Юникода. column вызовы wcspbrk для поиска input_separator (т. е. $'x99' ) во входном потоке. Поскольку строка 0x99 является недопустимой последовательностью UTF-8, column вызывает wcspbrk в NULL качестве второго аргумента, и это вызывает ошибку seg.

column При анализе входных аргументов отсутствует проверка, она не проверяет , является ли возвращаемое значение mbs_to_wcs , которое вызывает mbstowcs проверку переданной строки -s NULL . Это можно было бы исправить с помощью чего-нибудь еще:

test3

Возможность -d paste и возможность -s column
укажите набор разделителей. paste -d "x99" Вставки просто x , и поскольку -s "x99" x они находятся в наборе разделителей, они просто разделяются по x символу.

test4

Также кажется, что столбцы преобразуют разбитые последовательности, например $'x99' , в x99 форму точно так же, как при чтении с входных данных. Из-за этого при paste вставке 0x99 байта вы можете установить -s x99 , потому column что преобразуете байт на входе в 4 байта x 9 9 и после этого работаете над входом, чтобы разбить его на столбцы.

Затем -s x99 последовательно обнаруживает 4 разделителя x 9 9 , так что вы получаете много пробелов.

В любом случае, решение в любом случае состоит в том, чтобы использовать байты меньше 128.

Я отправил вопрос util-linux на github https://github.com/karelzak/util-linux/issues/1425 и проблема, скорее всего, будет исправлена, и, похоже, в следующей column версии появится сообщение об ошибке, когда команде будет передана недопустимая последовательность UTF-8 -s .

Проблема была исправлена в вышестоящем репозитории util-linux (https://github.com/karelzak/util-linux/commit/9714331843ef3a6d9c10ff1d3bc5fcf53d44d930) и изменение будет доступно в следующем выпуске.

Кто-нибудь может объяснить результат приведенных выше тестов?

test1 и test2

Столбец пытается использовать языковой стандарт (т. е. UTF-8) для анализа входных данных, 0x99 сам по себе (без предшествования 0xc2 ) является недопустимой последовательностью Юникода.

Существует ошибка, из-за column которой не проверяется, является ли переданная строка -s допустимой строкой Юникода. column вызовы wcspbrk для поиска input_separator (т. е. $'x99' ) во входном потоке. Поскольку строка 0x99 является недопустимой последовательностью UTF-8, column вызывает wcspbrk в NULL качестве второго аргумента, и это вызывает ошибку seg.

column При анализе входных аргументов отсутствует проверка, она не проверяет , является ли возвращаемое значение mbs_to_wcs , которое вызывает mbstowcs проверку переданной строки -s NULL . Это можно было бы исправить с помощью чего-нибудь еще:

test3

Возможность -d paste и возможность -s column
укажите набор разделителей. paste -d "x99" Вставки просто x , и поскольку -s "x99" x они находятся в наборе разделителей, они просто разделяются по x символу.

test4

Также кажется, что столбцы преобразуют разбитые последовательности, например $'x99' , в x99 форму точно так же, как при чтении с входных данных. Из-за этого при paste вставке 0x99 байта вы можете установить -s x99 , потому column что преобразуете байт на входе в 4 байта x 9 9 и после этого работаете над входом, чтобы разбить его на столбцы.

Затем -s x99 последовательно обнаруживает 4 разделителя x 9 9 , так что вы получаете много пробелов.

В любом случае, решение в любом случае состоит в том, чтобы использовать байты меньше 128.

Я отправил вопрос util-linux на github https://github.com/karelzak/util-linux/issues/1425 и проблема, скорее всего, будет исправлена, и, похоже, в следующей column версии появится сообщение об ошибке, когда команде будет передана недопустимая последовательность UTF-8 -s .

Проблема была исправлена в вышестоящем репозитории util-linux (https://github.com/karelzak/util-linux/commit/9714331843ef3a6d9c10ff1d3bc5fcf53d44d930) и изменение будет доступно в следующем выпуске.

Кто-нибудь может объяснить результат приведенных выше тестов?

test1 и test2

Столбец пытается использовать языковой стандарт (т. е. UTF-8) для анализа входных данных, 0x99 сам по себе (без предшествования 0xc2 ) является недопустимой последовательностью Юникода.

Существует ошибка, из-за column которой не проверяется, является ли переданная строка -s допустимой строкой Юникода. column вызовы wcspbrk для поиска input_separator (т. е. $'x99' ) во входном потоке. Поскольку строка 0x99 является недопустимой последовательностью UTF-8, column вызывает wcspbrk в NULL качестве второго аргумента, и это вызывает ошибку seg.

column При анализе входных аргументов отсутствует проверка, она не проверяет , является ли возвращаемое значение mbs_to_wcs , которое вызывает mbstowcs проверку переданной строки -s NULL . Это можно было бы исправить с помощью чего-нибудь еще:

test3

Возможность -d paste и возможность -s column
укажите набор разделителей. paste -d "x99" Вставки просто x , и поскольку -s "x99" x они находятся в наборе разделителей, они просто разделяются по x символу.

test4

Также кажется, что столбцы преобразуют разбитые последовательности, например $'x99' , в x99 форму точно так же, как при чтении с входных данных. Из-за этого при paste вставке 0x99 байта вы можете установить -s x99 , потому column что преобразуете байт на входе в 4 байта x 9 9 и после этого работаете над входом, чтобы разбить его на столбцы.

Затем -s x99 последовательно обнаруживает 4 разделителя x 9 9 , так что вы получаете много пробелов.

В любом случае, решение в любом случае состоит в том, чтобы использовать байты меньше 128.

Я отправил вопрос util-linux на github https://github.com/karelzak/util-linux/issues/1425 и проблема, скорее всего, будет исправлена, и, похоже, в следующей column версии появится сообщение об ошибке, когда команде будет передана недопустимая последовательность UTF-8 -s .

Проблема была исправлена в вышестоящем репозитории util-linux (https://github.com/karelzak/util-linux/commit/9714331843ef3a6d9c10ff1d3bc5fcf53d44d930) и изменение будет доступно в следующем выпуске.

Кто-нибудь может объяснить результат приведенных выше тестов?

test1 и test2

Столбец пытается использовать языковой стандарт (т. е. UTF-8) для анализа входных данных, 0x99 сам по себе (без предшествования 0xc2 ) является недопустимой последовательностью Юникода.

Существует ошибка, из-за column которой не проверяется, является ли переданная строка -s допустимой строкой Юникода. column вызовы wcspbrk для поиска input_separator (т. е. $'x99' ) во входном потоке. Поскольку строка 0x99 является недопустимой последовательностью UTF-8, column вызывает wcspbrk в NULL качестве второго аргумента, и это вызывает ошибку seg.

column При анализе входных аргументов отсутствует проверка, она не проверяет , является ли возвращаемое значение mbs_to_wcs , которое вызывает mbstowcs проверку переданной строки -s NULL . Это можно было бы исправить с помощью чего-нибудь еще:

test3

Возможность -d paste и возможность -s column
укажите набор разделителей. paste -d "x99" Вставки просто x , и поскольку -s "x99" x они находятся в наборе разделителей, они просто разделяются по x символу.

test4

Также кажется, что столбцы преобразуют разбитые последовательности, например $'x99' , в x99 форму точно так же, как при чтении с входных данных. Из-за этого при paste вставке 0x99 байта вы можете установить -s x99 , потому column что преобразуете байт на входе в 4 байта x 9 9 и после этого работаете над входом, чтобы разбить его на столбцы.

Затем -s x99 последовательно обнаруживает 4 разделителя x 9 9 , так что вы получаете много пробелов.

В любом случае, решение в любом случае состоит в том, чтобы использовать байты меньше 128.

Я отправил вопрос util-linux на github https://github.com/karelzak/util-linux/issues/1425 и проблема, скорее всего, будет исправлена, и, похоже, в следующей column версии появится сообщение об ошибке, когда команде будет передана недопустимая последовательность UTF-8 -s .

Проблема была исправлена в вышестоящем репозитории util-linux (https://github.com/karelzak/util-linux/commit/9714331843ef3a6d9c10ff1d3bc5fcf53d44d930) и изменение будет доступно в следующем выпуске.

Кто-нибудь может объяснить результат приведенных выше тестов?

test1 и test2

Столбец пытается использовать языковой стандарт (т. е. UTF-8) для анализа входных данных, 0x99 сам по себе (без предшествования 0xc2 ) является недопустимой последовательностью Юникода.

Существует ошибка, из-за column которой не проверяется, является ли переданная строка -s допустимой строкой Юникода. column вызовы wcspbrk для поиска input_separator (т. е. $'x99' ) во входном потоке. Поскольку строка 0x99 является недопустимой последовательностью UTF-8, column вызывает wcspbrk в NULL качестве второго аргумента, и это вызывает ошибку seg.

column При анализе входных аргументов отсутствует проверка, она не проверяет , является ли возвращаемое значение mbs_to_wcs , которое вызывает mbstowcs проверку переданной строки -s NULL . Это можно было бы исправить с помощью чего-нибудь еще:

test3

Возможность -d paste и возможность -s column
укажите набор разделителей. paste -d "x99" Вставки просто x , и поскольку -s "x99" x они находятся в наборе разделителей, они просто разделяются по x символу.

test4

Также кажется, что столбцы преобразуют разбитые последовательности, например $'x99' , в x99 форму точно так же, как при чтении с входных данных. Из-за этого при paste вставке 0x99 байта вы можете установить -s x99 , потому column что преобразуете байт на входе в 4 байта x 9 9 и после этого работаете над входом, чтобы разбить его на столбцы.

Затем -s x99 последовательно обнаруживает 4 разделителя x 9 9 , так что вы получаете много пробелов.

В любом случае, решение в любом случае состоит в том, чтобы использовать байты меньше 128.

Я отправил вопрос util-linux на github https://github.com/karelzak/util-linux/issues/1425 и проблема, скорее всего, будет исправлена, и, похоже, в следующей column версии появится сообщение об ошибке, когда команде будет передана недопустимая последовательность UTF-8 -s .

Проблема была исправлена в вышестоящем репозитории util-linux (https://github.com/karelzak/util-linux/commit/9714331843ef3a6d9c10ff1d3bc5fcf53d44d930) и изменение будет доступно в следующем выпуске.

Кто-нибудь может объяснить результат приведенных выше тестов?

test1 и test2

Столбец пытается использовать языковой стандарт (т. е. UTF-8) для анализа входных данных, 0x99 сам по себе (без предшествования 0xc2 ) является недопустимой последовательностью Юникода.

Существует ошибка, из-за column которой не проверяется, является ли переданная строка -s допустимой строкой Юникода. column вызовы wcspbrk для поиска input_separator (т. е. $'x99' ) во входном потоке. Поскольку строка 0x99 является недопустимой последовательностью UTF-8, column вызывает wcspbrk в NULL качестве второго аргумента, и это вызывает ошибку seg.

column При анализе входных аргументов отсутствует проверка, она не проверяет , является ли возвращаемое значение mbs_to_wcs , которое вызывает mbstowcs проверку переданной строки -s NULL . Это можно было бы исправить с помощью чего-нибудь еще:

test3

Возможность -d paste и возможность -s column
укажите набор разделителей. paste -d "x99" Вставки просто x , и поскольку -s "x99" x они находятся в наборе разделителей, они просто разделяются по x символу.

test4

Также кажется, что столбцы преобразуют разбитые последовательности, например $'x99' , в x99 форму точно так же, как при чтении с входных данных. Из-за этого при paste вставке 0x99 байта вы можете установить -s x99 , потому column что преобразуете байт на входе в 4 байта x 9 9 и после этого работаете над входом, чтобы разбить его на столбцы.

Затем -s x99 последовательно обнаруживает 4 разделителя x 9 9 , так что вы получаете много пробелов.

В любом случае, решение в любом случае состоит в том, чтобы использовать байты меньше 128.

Я отправил вопрос util-linux на github https://github.com/karelzak/util-linux/issues/1425 и проблема, скорее всего, будет исправлена, и, похоже, в следующей column версии появится сообщение об ошибке, когда команде будет передана недопустимая последовательность UTF-8 -s .

Проблема была исправлена в вышестоящем репозитории util-linux (https://github.com/karelzak/util-linux/commit/9714331843ef3a6d9c10ff1d3bc5fcf53d44d930) и изменение будет доступно в следующем выпуске.

Кто-нибудь может объяснить результат приведенных выше тестов?

test1 и test2

Столбец пытается использовать языковой стандарт (т. е. UTF-8) для анализа входных данных, 0x99 сам по себе (без предшествования 0xc2 ) является недопустимой последовательностью Юникода.

Существует ошибка, из-за column которой не проверяется, является ли переданная строка -s допустимой строкой Юникода. column вызовы wcspbrk для поиска input_separator (т. е. $'x99' ) во входном потоке. Поскольку строка 0x99 является недопустимой последовательностью UTF-8, column вызывает wcspbrk в NULL качестве второго аргумента, и это вызывает ошибку seg.

column При анализе входных аргументов отсутствует проверка, она не проверяет , является ли возвращаемое значение mbs_to_wcs , которое вызывает mbstowcs проверку переданной строки -s NULL . Это можно было бы исправить с помощью чего-нибудь еще:

test3

Возможность -d paste и возможность -s column
укажите набор разделителей. paste -d "x99" Вставки просто x , и поскольку -s "x99" x они находятся в наборе разделителей, они просто разделяются по x символу.

test4

Также кажется, что столбцы преобразуют разбитые последовательности, например $'x99' , в x99 форму точно так же, как при чтении с входных данных. Из-за этого при paste вставке 0x99 байта вы можете установить -s x99 , потому column что преобразуете байт на входе в 4 байта x 9 9 и после этого работаете над входом, чтобы разбить его на столбцы.

Затем -s x99 последовательно обнаруживает 4 разделителя x 9 9 , так что вы получаете много пробелов.

В любом случае, решение в любом случае состоит в том, чтобы использовать байты меньше 128.

Я отправил вопрос util-linux на github https://github.com/karelzak/util-linux/issues/1425 и проблема, скорее всего, будет исправлена, и, похоже, в следующей column версии появится сообщение об ошибке, когда команде будет передана недопустимая последовательность UTF-8 -s .

Проблема была исправлена в вышестоящем репозитории util-linux (https://github.com/karelzak/util-linux/commit/9714331843ef3a6d9c10ff1d3bc5fcf53d44d930) и изменение будет доступно в следующем выпуске.

Кто-нибудь может объяснить результат приведенных выше тестов?

test1 и test2

Столбец пытается использовать языковой стандарт (т. е. UTF-8) для анализа входных данных, 0x99 сам по себе (без предшествования 0xc2 ) является недопустимой последовательностью Юникода.

Существует ошибка, из-за column которой не проверяется, является ли переданная строка -s допустимой строкой Юникода. column вызовы wcspbrk для поиска input_separator (т. е. $'x99' ) во входном потоке. Поскольку строка 0x99 является недопустимой последовательностью UTF-8, column вызывает wcspbrk в NULL качестве второго аргумента, и это вызывает ошибку seg.

column При анализе входных аргументов отсутствует проверка, она не проверяет , является ли возвращаемое значение mbs_to_wcs , которое вызывает mbstowcs проверку переданной строки -s NULL . Это можно было бы исправить с помощью чего-нибудь еще:

test3

Возможность -d paste и возможность -s column
укажите набор разделителей. paste -d "x99" Вставки просто x , и поскольку -s "x99" x они находятся в наборе разделителей, они просто разделяются по x символу.

test4

Также кажется, что столбцы преобразуют разбитые последовательности, например $'x99' , в x99 форму точно так же, как при чтении с входных данных. Из-за этого при paste вставке 0x99 байта вы можете установить -s x99 , потому column что преобразуете байт на входе в 4 байта x 9 9 и после этого работаете над входом, чтобы разбить его на столбцы.

Затем -s x99 последовательно обнаруживает 4 разделителя x 9 9 , так что вы получаете много пробелов.

В любом случае, решение в любом случае состоит в том, чтобы использовать байты меньше 128.

Я отправил вопрос util-linux на github https://github.com/karelzak/util-linux/issues/1425 и проблема, скорее всего, будет исправлена, и, похоже, в следующей column версии появится сообщение об ошибке, когда команде будет передана недопустимая последовательность UTF-8 -s .

Проблема была исправлена в вышестоящем репозитории util-linux (https://github.com/karelzak/util-linux/commit/9714331843ef3a6d9c10ff1d3bc5fcf53d44d930) и изменение будет доступно в следующем выпуске.

Кто-нибудь может объяснить результат приведенных выше тестов?

test1 и test2

Столбец пытается использовать языковой стандарт (т. е. UTF-8) для анализа входных данных, 0x99 сам по себе (без предшествования 0xc2 ) является недопустимой последовательностью Юникода.

Существует ошибка, из-за column которой не проверяется, является ли переданная строка -s допустимой строкой Юникода. column вызовы wcspbrk для поиска input_separator (т. е. $'x99' ) во входном потоке. Поскольку строка 0x99 является недопустимой последовательностью UTF-8, column вызывает wcspbrk в NULL качестве второго аргумента, и это вызывает ошибку seg.

column При анализе входных аргументов отсутствует проверка, она не проверяет , является ли возвращаемое значение mbs_to_wcs , которое вызывает mbstowcs проверку переданной строки -s NULL . Это можно было бы исправить с помощью чего-нибудь еще:

test3

Возможность -d paste и возможность -s column
укажите набор разделителей. paste -d "x99" Вставки просто x , и поскольку -s "x99" x они находятся в наборе разделителей, они просто разделяются по x символу.

test4

Также кажется, что столбцы преобразуют разбитые последовательности, например $'x99' , в x99 форму точно так же, как при чтении с входных данных. Из-за этого при paste вставке 0x99 байта вы можете установить -s x99 , потому column что преобразуете байт на входе в 4 байта x 9 9 и после этого работаете над входом, чтобы разбить его на столбцы.

Затем -s x99 последовательно обнаруживает 4 разделителя x 9 9 , так что вы получаете много пробелов.

В любом случае, решение в любом случае состоит в том, чтобы использовать байты меньше 128.

Я отправил вопрос util-linux на github https://github.com/karelzak/util-linux/issues/1425 и проблема, скорее всего, будет исправлена, и, похоже, в следующей column версии появится сообщение об ошибке, когда команде будет передана недопустимая последовательность UTF-8 -s .

Проблема была исправлена в вышестоящем репозитории util-linux (https://github.com/karelzak/util-linux/commit/9714331843ef3a6d9c10ff1d3bc5fcf53d44d930) и изменение будет доступно в следующем выпуске.

Кто-нибудь может объяснить результат приведенных выше тестов?

test1 и test2

Столбец пытается использовать языковой стандарт (т. е. UTF-8) для анализа входных данных, 0x99 сам по себе (без предшествования 0xc2 ) является недопустимой последовательностью Юникода.

Существует ошибка, из-за column которой не проверяется, является ли переданная строка -s допустимой строкой Юникода. column вызовы wcspbrk для поиска input_separator (т. е. $'x99' ) во входном потоке. Поскольку строка 0x99 является недопустимой последовательностью UTF-8, column вызывает wcspbrk в NULL качестве второго аргумента, и это вызывает ошибку seg.

column При анализе входных аргументов отсутствует проверка, она не проверяет , является ли возвращаемое значение mbs_to_wcs , которое вызывает mbstowcs проверку переданной строки -s NULL . Это можно было бы исправить с помощью чего-нибудь еще:

test3

Возможность -d paste и возможность -s column
укажите набор разделителей. paste -d "x99" Вставки просто x , и поскольку -s "x99" x они находятся в наборе разделителей, они просто разделяются по x символу.

test4

Также кажется, что столбцы преобразуют разбитые последовательности, например $'x99' , в x99 форму точно так же, как при чтении с входных данных. Из-за этого при paste вставке 0x99 байта вы можете установить -s x99 , потому column что преобразуете байт на входе в 4 байта x 9 9 и после этого работаете над входом, чтобы разбить его на столбцы.

Затем -s x99 последовательно обнаруживает 4 разделителя x 9 9 , так что вы получаете много пробелов.

В любом случае, решение в любом случае состоит в том, чтобы использовать байты меньше 128.

Я отправил вопрос util-linux на github https://github.com/karelzak/util-linux/issues/1425 и проблема, скорее всего, будет исправлена, и, похоже, в следующей column версии появится сообщение об ошибке, когда команде будет передана недопустимая последовательность UTF-8 -s .

Проблема была исправлена в вышестоящем репозитории util-linux (https://github.com/karelzak/util-linux/commit/9714331843ef3a6d9c10ff1d3bc5fcf53d44d930) и изменение будет доступно в следующем выпуске.

Кто-нибудь может объяснить результат приведенных выше тестов?

test1 и test2

Столбец пытается использовать языковой стандарт (т. е. UTF-8) для анализа входных данных, 0x99 сам по себе (без предшествования 0xc2 ) является недопустимой последовательностью Юникода.

Существует ошибка, из-за column которой не проверяется, является ли переданная строка -s допустимой строкой Юникода. column вызовы wcspbrk для поиска input_separator (т. е. $'x99' ) во входном потоке. Поскольку строка 0x99 является недопустимой последовательностью UTF-8, column вызывает wcspbrk в NULL качестве второго аргумента, и это вызывает ошибку seg.

column При анализе входных аргументов отсутствует проверка, она не проверяет , является ли возвращаемое значение mbs_to_wcs , которое вызывает mbstowcs проверку переданной строки -s NULL . Это можно было бы исправить с помощью чего-нибудь еще:

test3

Возможность -d paste и возможность -s column
укажите набор разделителей. paste -d "x99" Вставки просто x , и поскольку -s "x99" x они находятся в наборе разделителей, они просто разделяются по x символу.

test4

Также кажется, что столбцы преобразуют разбитые последовательности, например $'x99' , в x99 форму точно так же, как при чтении с входных данных. Из-за этого при paste вставке 0x99 байта вы можете установить -s x99 , потому column что преобразуете байт на входе в 4 байта x 9 9 и после этого работаете над входом, чтобы разбить его на столбцы.

Затем -s x99 последовательно обнаруживает 4 разделителя x 9 9 , так что вы получаете много пробелов.

В любом случае, решение в любом случае состоит в том, чтобы использовать байты меньше 128.

Я отправил вопрос util-linux на github https://github.com/karelzak/util-linux/issues/1425 и проблема, скорее всего, будет исправлена, и, похоже, в следующей column версии появится сообщение об ошибке, когда команде будет передана недопустимая последовательность UTF-8 -s .

Проблема была исправлена в вышестоящем репозитории util-linux (https://github.com/karelzak/util-linux/commit/9714331843ef3a6d9c10ff1d3bc5fcf53d44d930) и изменение будет доступно в следующем выпуске.

Кто-нибудь может объяснить результат приведенных выше тестов?

test1 и test2

Столбец пытается использовать языковой стандарт (т. е. UTF-8) для анализа входных данных, 0x99 сам по себе (без предшествования 0xc2 ) является недопустимой последовательностью Юникода.

Существует ошибка, из-за column которой не проверяется, является ли переданная строка -s допустимой строкой Юникода. column вызовы wcspbrk для поиска input_separator (т. е. $'x99' ) во входном потоке. Поскольку строка 0x99 является недопустимой последовательностью UTF-8, column вызывает wcspbrk в NULL качестве второго аргумента, и это вызывает ошибку seg.

column При анализе входных аргументов отсутствует проверка, она не проверяет , является ли возвращаемое значение mbs_to_wcs , которое вызывает mbstowcs проверку переданной строки -s NULL . Это можно было бы исправить с помощью чего-нибудь еще:

test3

Возможность -d paste и возможность -s column
укажите набор разделителей. paste -d "x99" Вставки просто x , и поскольку -s "x99" x они находятся в наборе разделителей, они просто разделяются по x символу.

test4

Также кажется, что столбцы преобразуют разбитые последовательности, например $'x99' , в x99 форму точно так же, как при чтении с входных данных. Из-за этого при paste вставке 0x99 байта вы можете установить -s x99 , потому column что преобразуете байт на входе в 4 байта x 9 9 и после этого работаете над входом, чтобы разбить его на столбцы.

Затем -s x99 последовательно обнаруживает 4 разделителя x 9 9 , так что вы получаете много пробелов.

В любом случае, решение в любом случае состоит в том, чтобы использовать байты меньше 128.

Я отправил вопрос util-linux на github https://github.com/karelzak/util-linux/issues/1425 и проблема, скорее всего, будет исправлена, и, похоже, в следующей column версии появится сообщение об ошибке, когда команде будет передана недопустимая последовательность UTF-8 -s .

Проблема была исправлена в вышестоящем репозитории util-linux (https://github.com/karelzak/util-linux/commit/9714331843ef3a6d9c10ff1d3bc5fcf53d44d930) и изменение будет доступно в следующем выпуске.

Кто-нибудь может объяснить результат приведенных выше тестов?

test1 и test2

Столбец пытается использовать языковой стандарт (т. е. UTF-8) для анализа входных данных, 0x99 сам по себе (без предшествования 0xc2 ) является недопустимой последовательностью Юникода.

Существует ошибка, из-за column которой не проверяется, является ли переданная строка -s допустимой строкой Юникода. column вызовы wcspbrk для поиска input_separator (т. е. $'x99' ) во входном потоке. Поскольку строка 0x99 является недопустимой последовательностью UTF-8, column вызывает wcspbrk в NULL качестве второго аргумента, и это вызывает ошибку seg.

column При анализе входных аргументов отсутствует проверка, она не проверяет , является ли возвращаемое значение mbs_to_wcs , которое вызывает mbstowcs проверку переданной строки -s NULL . Это можно было бы исправить с помощью чего-нибудь еще:

test3

Возможность -d paste и возможность -s column
укажите набор разделителей. paste -d "x99" Вставки просто x , и поскольку -s "x99" x они находятся в наборе разделителей, они просто разделяются по x символу.

test4

Также кажется, что столбцы преобразуют разбитые последовательности, например $'x99' , в x99 форму точно так же, как при чтении с входных данных. Из-за этого при paste вставке 0x99 байта вы можете установить -s x99 , потому column что преобразуете байт на входе в 4 байта x 9 9 и после этого работаете над входом, чтобы разбить его на столбцы.

Затем -s x99 последовательно обнаруживает 4 разделителя x 9 9 , так что вы получаете много пробелов.

В любом случае, решение в любом случае состоит в том, чтобы использовать байты меньше 128.

Я отправил вопрос util-linux на github https://github.com/karelzak/util-linux/issues/1425 и проблема, скорее всего, будет исправлена, и, похоже, в следующей column версии появится сообщение об ошибке, когда команде будет передана недопустимая последовательность UTF-8 -s .

Проблема была исправлена в вышестоящем репозитории util-linux (https://github.com/karelzak/util-linux/commit/9714331843ef3a6d9c10ff1d3bc5fcf53d44d930) и изменение будет доступно в следующем выпуске.

Кто-нибудь может объяснить результат приведенных выше тестов?

test1 и test2

Столбец пытается использовать языковой стандарт (т. е. UTF-8) для анализа входных данных, 0x99 сам по себе (без предшествования 0xc2 ) является недопустимой последовательностью Юникода.

Существует ошибка, из-за column которой не проверяется, является ли переданная строка -s допустимой строкой Юникода. column вызовы wcspbrk для поиска input_separator (т. е. $'x99' ) во входном потоке. Поскольку строка 0x99 является недопустимой последовательностью UTF-8, column вызывает wcspbrk в NULL качестве второго аргумента, и это вызывает ошибку seg.

column При анализе входных аргументов отсутствует проверка, она не проверяет , является ли возвращаемое значение mbs_to_wcs , которое вызывает mbstowcs проверку переданной строки -s NULL . Это можно было бы исправить с помощью чего-нибудь еще:

test3

Возможность -d paste и возможность -s column
укажите набор разделителей. paste -d "x99" Вставки просто x , и поскольку -s "x99" x они находятся в наборе разделителей, они просто разделяются по x символу.

test4

Также кажется, что столбцы преобразуют разбитые последовательности, например $'x99' , в x99 форму точно так же, как при чтении с входных данных. Из-за этого при paste вставке 0x99 байта вы можете установить -s x99 , потому column что преобразуете байт на входе в 4 байта x 9 9 и после этого работаете над входом, чтобы разбить его на столбцы.

Затем -s x99 последовательно обнаруживает 4 разделителя x 9 9 , так что вы получаете много пробелов.

В любом случае, решение в любом случае состоит в том, чтобы использовать байты меньше 128.

Я отправил вопрос util-linux на github https://github.com/karelzak/util-linux/issues/1425 и проблема, скорее всего, будет исправлена, и, похоже, в следующей column версии появится сообщение об ошибке, когда команде будет передана недопустимая последовательность UTF-8 -s .

Проблема была исправлена в вышестоящем репозитории util-linux (https://github.com/karelzak/util-linux/commit/9714331843ef3a6d9c10ff1d3bc5fcf53d44d930) и изменение будет доступно в следующем выпуске.

Кто-нибудь может объяснить результат приведенных выше тестов?

test1 и test2

Столбец пытается использовать языковой стандарт (т. е. UTF-8) для анализа входных данных, 0x99 сам по себе (без предшествования 0xc2 ) является недопустимой последовательностью Юникода.

Существует ошибка, из-за column которой не проверяется, является ли переданная строка -s допустимой строкой Юникода. column вызовы wcspbrk для поиска input_separator (т. е. $'x99' ) во входном потоке. Поскольку строка 0x99 является недопустимой последовательностью UTF-8, column вызывает wcspbrk в NULL качестве второго аргумента, и это вызывает ошибку seg.

column При анализе входных аргументов отсутствует проверка, она не проверяет , является ли возвращаемое значение mbs_to_wcs , которое вызывает mbstowcs проверку переданной строки -s NULL . Это можно было бы исправить с помощью чего-нибудь еще:

test3

Возможность -d paste и возможность -s column
укажите набор разделителей. paste -d "x99" Вставки просто x , и поскольку -s "x99" x они находятся в наборе разделителей, они просто разделяются по x символу.

test4

Также кажется, что столбцы преобразуют разбитые последовательности, например $'x99' , в x99 форму точно так же, как при чтении с входных данных. Из-за этого при paste вставке 0x99 байта вы можете установить -s x99 , потому column что преобразуете байт на входе в 4 байта x 9 9 и после этого работаете над входом, чтобы разбить его на столбцы.

Затем -s x99 последовательно обнаруживает 4 разделителя x 9 9 , так что вы получаете много пробелов.

В любом случае, решение в любом случае состоит в том, чтобы использовать байты меньше 128.

Я отправил вопрос util-linux на github https://github.com/karelzak/util-linux/issues/1425 и проблема, скорее всего, будет исправлена, и, похоже, в следующей column версии появится сообщение об ошибке, когда команде будет передана недопустимая последовательность UTF-8 -s .

Проблема была исправлена в вышестоящем репозитории util-linux (https://github.com/karelzak/util-linux/commit/9714331843ef3a6d9c10ff1d3bc5fcf53d44d930) и изменение будет доступно в следующем выпуске.

Кто-нибудь может объяснить результат приведенных выше тестов?

test1 и test2

Столбец пытается использовать языковой стандарт (т. е. UTF-8) для анализа входных данных, 0x99 сам по себе (без предшествования 0xc2 ) является недопустимой последовательностью Юникода.

Существует ошибка, из-за column которой не проверяется, является ли переданная строка -s допустимой строкой Юникода. column вызовы wcspbrk для поиска input_separator (т. е. $'x99' ) во входном потоке. Поскольку строка 0x99 является недопустимой последовательностью UTF-8, column вызывает wcspbrk в NULL качестве второго аргумента, и это вызывает ошибку seg.

column При анализе входных аргументов отсутствует проверка, она не проверяет , является ли возвращаемое значение mbs_to_wcs , которое вызывает mbstowcs проверку переданной строки -s NULL . Это можно было бы исправить с помощью чего-нибудь еще:

test3

Возможность -d paste и возможность -s column
укажите набор разделителей. paste -d "x99" Вставки просто x , и поскольку -s "x99" x они находятся в наборе разделителей, они просто разделяются по x символу.

test4

Также кажется, что столбцы преобразуют разбитые последовательности, например $'x99' , в x99 форму точно так же, как при чтении с входных данных. Из-за этого при paste вставке 0x99 байта вы можете установить -s x99 , потому column что преобразуете байт на входе в 4 байта x 9 9 и после этого работаете над входом, чтобы разбить его на столбцы.

Затем -s x99 последовательно обнаруживает 4 разделителя x 9 9 , так что вы получаете много пробелов.

В любом случае, решение в любом случае состоит в том, чтобы использовать байты меньше 128.

Я отправил вопрос util-linux на github https://github.com/karelzak/util-linux/issues/1425 и проблема, скорее всего, будет исправлена, и, похоже, в следующей column версии появится сообщение об ошибке, когда команде будет передана недопустимая последовательность UTF-8 -s .

Проблема была исправлена в вышестоящем репозитории util-linux (https://github.com/karelzak/util-linux/commit/9714331843ef3a6d9c10ff1d3bc5fcf53d44d930) и изменение будет доступно в следующем выпуске.

Кто-нибудь может объяснить результат приведенных выше тестов?

test1 и test2

Столбец пытается использовать языковой стандарт (т. е. UTF-8) для анализа входных данных, 0x99 сам по себе (без предшествования 0xc2 ) является недопустимой последовательностью Юникода.

Существует ошибка, из-за column которой не проверяется, является ли переданная строка -s допустимой строкой Юникода. column вызовы wcspbrk для поиска input_separator (т. е. $'x99' ) во входном потоке. Поскольку строка 0x99 является недопустимой последовательностью UTF-8, column вызывает wcspbrk в NULL качестве второго аргумента, и это вызывает ошибку seg.

column При анализе входных аргументов отсутствует проверка, она не проверяет , является ли возвращаемое значение mbs_to_wcs , которое вызывает mbstowcs проверку переданной строки -s NULL . Это можно было бы исправить с помощью чего-нибудь еще:

test3

Возможность -d paste и возможность -s column
укажите набор разделителей. paste -d "x99" Вставки просто x , и поскольку -s "x99" x они находятся в наборе разделителей, они просто разделяются по x символу.

test4

Также кажется, что столбцы преобразуют разбитые последовательности, например $'x99' , в x99 форму точно так же, как при чтении с входных данных. Из-за этого при paste вставке 0x99 байта вы можете установить -s x99 , потому column что преобразуете байт на входе в 4 байта x 9 9 и после этого работаете над входом, чтобы разбить его на столбцы.

Затем -s x99 последовательно обнаруживает 4 разделителя x 9 9 , так что вы получаете много пробелов.

В любом случае, решение в любом случае состоит в том, чтобы использовать байты меньше 128.

Я отправил вопрос util-linux на github https://github.com/karelzak/util-linux/issues/1425 и проблема, скорее всего, будет исправлена, и, похоже, в следующей column версии появится сообщение об ошибке, когда команде будет передана недопустимая последовательность UTF-8 -s .

Проблема была исправлена в вышестоящем репозитории util-linux (https://github.com/karelzak/util-linux/commit/9714331843ef3a6d9c10ff1d3bc5fcf53d44d930) и изменение будет доступно в следующем выпуске.