Кто чем заменяет пробелы в именах файлов?

культяпко-говнотыки не умеют работать с файлами с кириллицей.

WUT

вдруг где-то байт 5-и битам окажется равен

А вдруг где-то байт из двух бит будет состоять? Что ты фантастику тут выдумываешь?

Хотя, в принципе, сейчас похрену, всё равно всё в гуе. Можно и пробелами.

имя-файла

Пробелы в именах книг и фильмов ничем не заменяю, автодополнение есть же и в скриптах эти файлы не нужны. В остальных просто не использую. Ну или example-file-name.sh

В гуе фильм долго искать и запускать. Нахер гуй.

Как угодно, ибо не использую убогий баш, в котором от этого могут быть проблемы.

fish?

%20

Python для скриптов, fish для оболочки.

А вдруг где-то байт из двух бит будет состоять?

Было уже: «Название «байт» было впервые использовано в июне 1956 года В. Бухгольцем при проектировании первого суперкомпьютера IBM 7030 Stretch для пучка одновременно передаваемых в устройствах ввода-вывода битов числом от одного до шести. Позже, в рамках того же проекта, байт был расширен до восьми бит» ©.

В наше время 1 байт === 8 бит. И если где-то не так, то я соболезную.

Code::Blocks.

Куча софта в Linux не умеет работать с пробелами или спотыкается на Unicode, хотя на дворе 2019 год.

Это ты ещё софт под windows не видел как запускают, который кроме ascii символов в путях знать ни о чём не знает.

я нигде не говорил, что в пробелы не может ЭКСКЛЮЗИВНЫЙ софт под Linux.

К чему тогда вызывающе неверный пафос про «Куча софта в Linux не умеет работать с пробелами»? Когда на деле выясняется, что звучать это должно «до сих пор иногда можно встретить софт, обычно кросплатформенный, не работающий с пробелами»?

Почему ты кросс-платформенный софт под Linux не считаешь софтом в Linux, софтварный нацист?

Windows я не так интенсивно пользуюсь, бог миловал.

Не знаю что там за проблемы с пробелами, но там есть проблема гораздо хуже сабжевой – это мешанина из CP-866, Win-1251 и Unicode.

Ага, и переключение cmd в utf8 ломает more.

Почему? Единственный адекватный вариант, ИМХО.

+1

Пишу пробелы пробелами и спецсимволы спецсимволами. А вы что, нет?

(Кроме технических файлов, исходников и всего такого. Тогда пишу так, как принято, или в pure-ascii-snake-case).

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

Второй вариант. Третий тоже не люблю, но он каноничный...

• имя-файла - типа лисп

this one

основная проблема с торрентами, их часто альтернативно одаренные выкладывают. там встречаются не только пробелы, но и юникодные символы в перемешку с cp1251, отданной под видом юникода или еще бог знает чего. из-за вот таких вот одаренных пришлось отдельный санитайзер написать, благо недолго. всякое говно из первой половины ascii-таблицы, требующее удержания шифта, удаляется, пробелы заменяются точками, '&' - 'n' и т.д.

все это заметно облегчает потом не только доступ в консоли, но обработку этих же файлов в цикле, без while ... read ...

Дата регистрации: 01.04.19 11:19:59

Всю дорогу использовал пробелы в именах, никогда проблем не попадалось.

не звучит. просто не сталкивался.

За 20 лет?

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

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

Даёшь 8.3!

и ни разу не скриптовал работу с файлами и пробелами?

Много раз. А что, в этом есть какие-то проблемы? Я, конечно, много раз встречал кривые скрипты с проблемами с экранированием, даже на ЛОРе, но это всегда было от непонимания принципов работы баша и экранирования. Мне показалось, или на лоре есть пользователь Xintrea и он автор? (комментарий) Не работает скрипт: слишком много аргументов (комментарий)

экранироваться пробел может разными способами

И что?

нафига этот геморой

Какой гемморой?

Зачем себя так сильно ограничивать, если длина файла может составлять 255 символов (конечно, если ты не хрюникодчик)?

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

как ты делаешь рекурсивную обработку имен с пробелами?

Можно пример задачи? Обычно я рекурсивный обход делаю через find -print0, но, может, я как-то не так понимаю вопрос.

да, вопрос я задал так себе. пример простой.

dir1 - > dir2 -> file2.1.jpg
  |       |____> file2.2.mp3
  |
  |----> file1.1.txt
  |----> file1.2.mp3

ну вот ты хочешь пройтись по файлам и выполнить серию действий. например, прочитать метаинфу и с условием этого что-то сделать.

for F in `find ...`;
do
     if ...
     elif ...
     else ...
done

выше имена файлов (file*) содержат пробелы, мне просто лень было это как-то экранировать.

Так пойдёт? Для усложнения добавил ещё вложенное экранирование

#!/bin/bash

while read i ; do
  if [ ! -z "`file \"$i\" | grep ': PDF document'`" ]; then
    echo "\"$i\" is PDF"
  elif [ ! -z "`file \"$i\" | grep ': DjVu '`" ]; then
    echo "\"$i\" is DjVu"
  else
    echo "\"$i\" is unknown"
  fi
done < <(find "$1" -type f -print)

$ ./findtest.sh test
"test/2 2/Здравствуй японский язык!.djvu" is DjVu
"test/2 2/b b/Naoko Takei Moore, Kyle Connaughton - Donabe - 2015.pdf" is PDF
"test/2 2/b b/test.png" is unknown
"test/3 3/c c/Антонио Карлуччо - Pasta - 2014.pdf" is PDF
"test/3 3/c c/М. Дубровин - Иллюстрированный сборник идиом на 5 языках - 1997.djvu" is DjVu
"test/3 3/Сэйго Хатояма - Японская кухня (Япония. Иллюстрированный карманный путеводитель) - 2009.djvu" is DjVu
"test/3 3/test.txt" is unknown
"test/1 1/a a/Lingle B. - Fries! An Illustrated Guide to the World's Favorite Food - 2016.pdf" is PDF
"test/1 1/10mifov.pdf" is PDF
"test/1 1/test.ods" is unknown

for F in `find

Когда кто-то так делает, Аллах убивает одного котёнка. for только для известных списков:

for i in ${keys[*]}

for i in `cmd`

for только для известных списков:

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

done < <(find «$1» -type f -print)

а вот этого ответа я ждал и считаю, что эту хрень писать дольше, она сложнее, вероятность ошибки и опечатки выше. чем просто for ...

т.е. я считаю проблемой саму конструкцию while read ... и особенно done < <(cmd) вот это перенаправление. я однотипно буду использовать for ... для разных операций. и для файлов, и не только. а ты будешь каждый раз стряпать свой набор из смайликов и если не там пробел поставишь, то еще и глюканет.

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

И будешь «испытывать этот гемморой» © ты.

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

И у меня будет всегда всё работать с первого раза, и я не буду испытывать никакого геммороя. Каждому своё.

приведи мне пример проблемы с for

И у меня будет всегда всё работать с первого раза, и я не буду испытывать никакого геммороя.

ну блин... ты, конечно, сходу скажешь, почему ты используешь два («< <») для перенаправления? кто-то используют три. и конечно сходу скажешь, почему <(cmd) а не $(cmd)

к слову о проблемах со спейсами. locate выдает без экранирования, ты копируешь, вставляешь, а bash требует экранирования. вот тебе и гемморой.