/usr/xpg4/bin/grep -q [^0-9] не всегда работает должным образом

У меня есть сценарий Unix ksh, который используется ежедневно в течение многих лет (запускается ночью с помощью crontab). В последнее время одна функция в скрипте ведет себя хаотично, как никогда раньше. Пробовал разными способами выяснить причину, но безуспешно.

Функция проверяет входную строку, которая должна быть строкой из 10 числовых символов. Функция проверяет, равна ли длина строки 10 и содержит ли она какие-либо нечисловые символы:

#! /bin/ksh

# The function:
is_valid_id () {
   # Takes one argument, which is the ID being tested.
   if [[ $(print ${#1}) -ne 10 ]] || print "$1" | /usr/xpg4/bin/grep -q [^0-9] ; then
      return 1
   else
      return 0
   fi
}

cat $input_file | while read line ; do
   id=$(print $line | awk -F: '{print $5}')
   # Calling the function:
   is_valid_id $id
   stat=$?
   if [[ $stat -eq 1 ]] ; then
      print "The ID $id is invalid.  Request rejected.\n" >> $ERRLOG
      continue
   else
      ...
   fi
done

Проблема с функцией заключается в том, что каждую ночь из десятков или сотен запросов она находит идентификаторы в нескольких запросах недействительными. Я визуально проверил входные данные и обнаружил, что все «недопустимые» идентификаторы на самом деле являются строками из 10 числовых символов, как и должно быть. Эта ошибка кажется случайной, потому что она возникает только с некоторыми запросами. Однако, хотя отклоненные запросы постоянно возвращаются, одни и те же идентификаторы постоянно выбираются как недействительные день за днем.

Я сделал следующее:

1. Машина Unix работает уже почти год, поэтому может потребоваться обновление. Системный администратор перезагрузил машину по моей просьбе. Но проблема сохраняется после перезагрузки.
2. Я вручную запустил точно такие же два теста в функции, в командной строке, и все идентификаторы, которые были признаны недействительными ночью, действительны.
3. Я знаю, что одни и те же команды могут вести себя по-разному при вызове вручную или в сценарии. Чтобы увидеть, как функция ведет себя в сценарии, приведенный выше отрывок кода представляет собой небольшой сценарий, который я запустил, чтобы воспроизвести проблему. И действительно, некоторые (хотя и не все) идентификаторы, признанные недействительными ночью, также признаются недействительными с помощью небольшого сценария устранения неполадок.
4. Затем я изменил этот сценарий устранения неполадок, чтобы запускать два теста по одному, и обнаружил, что именно тест /usr/xpg4/bin/grep -q [^0-9] ошибочно находит некоторые идентификаторы как содержащие нечисловые символы. Ну, идентификаторы - это все числовые символы, по крайней мере, визуально.
5. Я проверил, нет ли проблем с командным файлом xpg4 grep (ls -l /usr/xpg4/bin/grep), чтобы убедиться, что он добавлен туда недавно. Но его отметка времени - 2005 год (эта машина работает под управлением Solaris 10).
6. Зная, что данные поступают из центральной ERP-системы, ввод данных в которую осуществляется из разных мест с использованием всевозможных терминальных машин, работающих под управлением всевозможных операционных систем, поддерживающих различные наборы символов и кодировки. Система ERP просто позволяет им это делать. Но могут ли символы из других кодировок визуально отображаться как числовые символы, но закодированные значения не такие, как ожидает команда /usr/xpg4/bin/grep на нашей машине Unix? Я попробовал команду od (восьмеричный дамп), но она мне не очень помогает, так как я с ней не знаком. Может быть, мне нужно больше узнать о od для решения этой проблемы.

Мой временный обходной путь — пропуск теста /usr/xpg4/bin/grep -q [^0-9]. Но проблема не решена. Что я могу попробовать дальше?