Возможно через bash записать каждую строку из текстового файла в отдельные файлы в зависимости от первого символа строки?

Взять строчку, выдрать из неё первую букву, дописать результат в $1_out.txt

Даже sed не нужен.

Круто! …но пока мало что понятно. Но я разберусь. Спасибо.

умом я это понимаю. Нет навыков написания на bash.

Бульварное чтиво минут на 40.

cat source.file | while read line; do

Ох. Вот такая конструкция выдаёт так себе понимание bash и вообще системы.

case $firstsymbol in

И таки правильнее case "$firstsymbol" in

интересно. А как сделать правильно, через перенаправление?

а чем пример выше плох?

а чем пример выше плох?

В эталонной ненужности: разбазариванию ресурсами, неудобностью в использовании за счёт работы в новом процессе и в котором уже нет далее изначального stdin.

конструкция выдаёт так себе понимание bash

Ты так говоришь, будто бы Баш вообще можно понять.

разбазариванию ресурсами

Один лишний процесс для разовой задачи - разбазаривание ресурсов?

неудобностью в использовании за счёт работы в новом процессе

И в чем же неудобство?

Advanced Bash-Scripting Guide

минут на 40

«Вы, наверное, шутите, мистер Фейнман!..»

https://porkmail.org/era/unix/award.html

https://porkmail.org/era/unix/award.html

The right way to do this is

    	while read f; do
    	    ...
    	done <file

Он -r у read забыл.

И в чем же неудобство?

Вот вы посчитали, сколько добавили строк в каждый файл. Цикл у вас закончился, а результаты в переменных были в соседнем процессе.

правильнее закопать стюардессу и не использовать bash, если на это нет серьёзных причин, конечно (например, стив борн взял в заложники твоего котика)

и не надо, если на собеседовании тебя просят что-то написать на баше - безопаснее всего для психики уйти с него

правильнее закопать стюардессу

Ну меня то точно bash переживёт. Вопрос то в том, что у хающих как всегда сплошной детский сад, ведь принцип «компьютер железный, и так сойдёт» работает только если код облегчает работу человеку, ему удобнее и нагляднее. Но нет же, нарисуют побольше всяких абсолютно ненужных выкрутасов, которые только усложняют работу, а потом визжат — как сложно.

Возможно. Составь алгоритм. Он должен быть примерно такой: читать строки построчно, отрезать первый символ каждой строки в переменную или нужное тебе число символов, выводить строку в файл с именем составленным из значения переменной и нужной тебе последовательности символов.

Даже проверок на наличие файла можно не делать.

Реализуй алгоритм на базе, тебе понадобятся: цикл, программа для отрезания части строки, либо сам баш, либо sed, cut, awk.

Зачем так сложно, автор темы написал, что ему нужно выводить в файл, имя которого будет соответствовать первой букве строки.

Если исходить из этого, то просто:

вывод файла | пока читаем в переменную STR 
делаем
  VAR=`отрезать от STR первый символ`
  вывод $STR > ${VAR}.out.txt
конец

И делов-то.

Как ТЗ составлено так и делай.

ТЗ внимательно прочти.

по-моему такое стоит делать на авк. авк-код можно вместо однострочника положить в файл, и выполнить через awk -f

$ cat input.txt | awk '{ 
    outfile="symb.out";
    if (substr($1,0,1) == "a") { outfile="out_a.txt"};
    if (substr($1,0,1) == "b") { outfile="out_b.txt"};
    if (substr($1,0,1) ~ /[0-9]/) { outfile="dig_out.txt"};
    print $0 > outfile ; 
}'


$ grep -H '' symb.out out_a.txt out_b.txt  dig_out.txt 
symb.out:_vasilii
out_a.txt:anton
out_a.txt:andre
out_b.txt:boris
dig_out.txt:1igor

Код с cat понятнее. Довольно странно указывать входной файл в конце.

Пример выше плох тем, что слишком хорошо читается человеком. Не хватает налёта элитарности баш-хакеров, что ли.

Код с cat понятнее. Довольно странно указывать входной файл в конце.

Ну конечно, конечно, у cat то не в конце обрабатываемые файлы то указываются... Вон тут уже появляются cat file | awk, ага, так понятнее, ну да, ну да... Типичный детсад, назло дидам отморожу уши.

Ну конечно, конечно, у cat то не в конце обрабатываемые файлы то указываются…

Нет конечно, в начале указываются. Сначала cat filename |, а потом куда этот файл выводить.

назло дидам отморожу уши.

ID: 214

Вот уж диды так диды.

Нет конечно,

Виляете. Да и вообще, обрабатываемые файлы — это не часть программы, а вообще-то аргументы программы, как у cat — показать файл человеку, вот единственно разумное применение данной программы, скрипту эта вспомогательная программа в принципе не нужна, url с длинным объяснением по английски, почему это так тут уже приводили выше.

Важно как выглядит код, а то что cat – это отдельная программа – это незначительная деталь реализации.

Буду везде писать cat <file> | потому что это красивее и понятнее.

Какой же ты скучный

#!/bin/bash

FILE=$1;

for letter in {a..z}; do
    echo -n '' > "${letter}_out.txt";
done
echo -n '' > "symb.out";
echo -n '' > "dig.out";

for letter in {a..z}; do
    cat $FILE | grep -i "^$letter" >> "${letter}_out.txt";
done

for digit in {0..9}; do
    cat $FILE | grep -i "^$digit" >> "dig.out";
done

cat $FILE | grep -i '[^0-9^a-z]' >> "symb.out";

for letter in {a..z}; do
    if [ ! -s "${letter}_out.txt" ]; then
        rm "${letter}_out.txt";
    fi
done
if [ ! -s "dig.out" ]; then
    rm "dig.out";
fi
if [ ! -s "symb.out" ]; then
    rm "symb.out";
fi

Какой же ты скучный

Не, когда коту делать нечего, то яйца должны быть до блеска, а у вас массивов не хватает, со статусами файлов, а то удалите пустые, но уже имеющиеся до вызова файлы...

когда коту делать нечего

Специально поглядел, файл a.txt сделал ровно в 18:00, а в 18:07 запостил комент.

у вас массивов не хватает, со статусами файлов

С массивами я где-то раньше уже какой-то скрипт делал. Уже не интересно.

Специально поглядел, файл a.txt сделал ровно в 18:00, а в 18:07 запостил комент.

Хотелось бы верить, но с вашим скриптом, обнуляющим всё подряд, про modify time говорить не приходится :)

С массивами я где-то раньше уже какой-то скрипт делал. Уже не интересно.

Не скажите, сколько красивых значков бы добавилось.

обнуляющим всё подряд

Не всё подряд, в a.txt я данные из оп скопипастил.

Не всё подряд, в a.txt я данные из оп скопипастил.

Какой же ты скучный

Код с cat понятнее.

Кому понятнее?

Адекватному человеку

Ну меня то точно bash переживёт.

это не значит, что нужно им пользоваться

Вопрос то в том, что у хающих как всегда сплошной детский сад, ведь принцип «компьютер железный, и так сойдёт» работает только если код облегчает работу человеку, ему удобнее и нагляднее.

так я о чём твержу! код должен быть удобнее и нагляднее, а не как в bash-е обычно

солгласен с замечаниями по-поводу

done < file

и

while read -r

однако не ставил себе целью сделать по фен-шую, а просто показал по наитию как вообще можно сделать

солгласен с замечаниями по-поводу

А что не согласны насчёт кавычек для case? Оно же развернет первый символ, если он спецсимвол.

с переменной в кавычках тоже согласен как бестпрактис.

Можно так,

#!/usr/bin/env bash
while read -r LINE; do
    first_char="${LINE:0:1}"
    if [[ ${first_char} = [[:alpha:]] ]]; then
        echo "${LINE}" >> "${first_char,,}"_"${2:?}"
    elif [[ ${first_char} = [[:digit:]] ]]; then
        echo "${LINE}" >> "dig_${2:?}"
    else
        echo "${LINE}" >> "symb_${2:?}"
    fi
done < "${1:?}"

# ./script.sh in.text out.text

Есть сомнение в адекватности людей, желающих, чтобы был понятен незнакомый им язык.

незнакомый - это понятно, вопрос в количестве усилий, которые надо приложить, чтобы начать понимать

Правильно. Но в случае с башем люди почему-то усилий вообще не прилагают.

cat input.txt | awk

За это тоже по рукам указкой.

cat $FILE | grep

Из это тоже.

Вспомнил еще:

При использовании конвейера (пайп), переменные объявленные в цикле, не будут доступны за его пределами.

cat in.text | while read LINE; do
    echo "${LINE}"
    var1="null"
done
echo "$var1"

Если передача идет не через пайп, то переменные доступны:

while read LINE; do
    echo "${LINE}"
    var1="null"
done < in.text
echo "$var1"

возможно потому, что затраченные усилия того не стоят?

интерактивно есть более удобные оболочки, как язык для скриптования есть гораздо более удобные и читабельные языки, а в каком-нибудь обрезанном эмбеддеде один хрен будет sh/busybox

а ubiquity в 2022 году - слабый аргумент для сетевой операционной системы