Завершение строк в следующем файле не является единообразным
Я использую Windows 10 home и обычно использую Visual Studio Code (VSCODE) для редактирования сценариев Linux Bash, а также PHP и JavaScript.
Я не разрабатываю ничего, предназначенного для Windows, и я не возражаю, что EOL по умолчанию для всех файлов, которые я редактирую, будет Unix-подобным (nix).
Как я могу гарантировать, что все EOL во всех файлах (с любым расширением файла) являются nix в VSCODE?
Я задаю этот вопрос после того, как я написал несколько сценариев Bash в Windows для VSCODE, загрузил их в GitHub в рамках проекта, и один из старших программистов, который просматривал проект, сказал мне, что у меня есть Windows EOLs а также проблему BOM , которую я мог бы решить, если я заменю EOL на nix (или, по крайней мере, я так понял).
Поскольку вся моя разработка ориентирована на Linux, я бы предпочел, чтобы по умолчанию любой файл, который я редактировал, имел nix EOL, даже если он уникален для Window.
4 ответа
В настройках вашего проекта добавьте / отредактируйте следующую опцию конфигурации:
Это было добавлено с момента коммита 639a3cb, поэтому вам, очевидно, потребуется использовать версию после что совершать.
Примечание. Даже если в файле есть один CRLF , вышеуказанная настройка будет проигнорирована, и весь файл будет преобразован в CRLF . Сначала нужно преобразовать все CRLF в LF , прежде чем вы сможете открыть его в коде Visual Studio.
У меня была та же проблема - редактирование файлов в окнах, обычно предназначенных для Unix-сервера (с использованием потрясающего плагина ftp-sync), и почти всегда требовалось окончание строк LF. Мне потребовалось смущающе много времени, чтобы заметить текущую настройку в правом нижнем углу, и если вы нажмете на нее, вы можете переключить настройку только для текущего файла.
Чтобы преобразовать окончание строки для существующих файлов
Мы можем использовать dos2unix в WSL или в вашем терминале Shell.
Конвертировать окончания строк в текущем каталоге:
Если есть некоторые папки, которые вы хотите исключить из конверсии, используйте:
Оба существующих ответа полезны, но не то, что мне было нужно. Я хотел массово преобразовать все символы новой строки в моем рабочем пространстве из CRLF в LF.
описание ошибки: No such file or directory: '/content/drive/MyDrive/Education/Lerning_year_2021_2022/Hack_the_organic/data/train_images/train_2/image2.jpg' Изначально изображений было 320, и ошибка .
Перенаправление трафика на защищённый айпи Алена
Разные способы перемещения объекта WPF
Помогите, пожалуйста, с одной проблемой. У меня в Grid сетке, в одной из ячеек есть изображение. И точно такое же изображение находится в другой Grid сетке, которая вложена в первую. Мне нужно .
Как работать в Selenium c динамически подгружаемыми кнопками и формами на веб-странице?
Суть такова - нужно с помощью Selenium выполнить вход в сбер, а если логин или пароль введён неправильно - нажать на восстановить доступ, но оно вот что-то не нажимается, хотя находится. Не бейте .
Как сделать вывод координат мыши, только если она попадает в определённую область
Необходимо, чтобы координаты мыши выводились только тогда, когда происходит нажатие на мышь в определённой зоне(допустим зона имеет форму квадрата.) Сделал небольшой код, но почему-то условие if не .
Сервис, который разворачивает контейнеры на поддоменах
Хочу погрузиться в обучение разработки веб сервисов, которые разворачиваются на поддоменах. Сейчас так работают множество сервисов, но я не могу найти лучшее решение, как их реализовать. Даже не могу .
Возможно ли сделать, чтобы цикл for перебирал одновременно словарь и список?
all_schedule = [data_1(), data_2(), data_3(), data_4(), data_5()] for chanes, shedule in check.values(), all_schedule: if list(schedule) != changes: print('Расписание изменилось') .
2 ответа
Чтобы быть более последовательным и иметь возможность указывать конец строки для разных файлов по расширению, вы можете использовать файл .gitattributes. Файл будет сохранен в репозитории и переопределит настройку разработчика. Файл .gitattributes должен быть создан в корне репозитория и зафиксирован в репо, как и любой другой файл.
Привет, Дэвид - на самом деле у меня уже есть файл gitattributes - как указано в моем исходном вопросе. Есть ли что-то, что я должен изменить в текущем файле, который я использую?
Python (pyautogui) отлавливать происходящее на экране
Как отлавливать происходящее на экране быстро? import pyautogui template = pyautogui.locateOnScreen('screen.jpg') print(template) Работает очень долго. Я хочу делать скриншот экрана и проверять, есть .
Не могу сделать отправку в Github из VS Code
При попытке опубликовать ветвь выдает ошибку в VS code "У вас нет разрешений на отправку в GitHub. Вы хотите создать вилку и выполнить отправку в нее?" Почему я не могу опубликовать ветвь? .
Помогите решить проблему Вызвано исключение по адресу 0x00007FF7E367ACDD 0xC0000005: нарушение прав доступа при записи по адресу 0x0000027ACDAA423D 0x
пример
Вы теперь редактируете это
Git diff покажет:
Другими словами, это показывает больший различие, чем концептуально произошло. Это показывает, что вы удалили строку > и добавили строку >\n . Фактически это то, что произошло, но это не то, что концептуально произошло, поэтому это может сбить с толку.
Мы можем написать то же самое в другом направлении: если вы удалите новую строку в конце существующего файла, в которой уже есть новая строка в конце, diff покажет старую последнюю строку также как измененную, если концептуально это не так. По крайней мере, одна веская причина, чтобы удалить перевод строки в конце.
@gentiane Вы путаете "новую строку" (новую строку) и "новую строку" (1 или 2 символа, разделяющие конец строки)
@minexew Нет, Джентиан нет. Возможно, вы просто не понимаете, что «новая строка» - это то же самое, что и «новая строка».
@TheincredibleJan То, как они используются в ответе, два термина имеют разные значения. Я не знаю, пытаетесь ли вы быть умницей или просто не понимаете, что происходит.
Предположим, например, что файл с символом перевода строки рассматривается как одна пустая строка. И наоборот, файл с длиной нулевых байтов на самом деле является пустым файлом с нулевыми строками. Это может быть подтверждено в соответствии с wc -l командой.
В целом, это поведение разумно, потому что не было бы никакого другого способа отличить пустой текстовый файл от текстового файла с одной пустой строкой, если бы \n символ был просто разделителем строки, а не разделителем строки. Таким образом, допустимые текстовые файлы всегда должны заканчиваться символом новой строки. Единственное исключение - текстовый файл должен быть пустым (без строк).
Я не отрицал вас, но этот ответ, по-видимому, специфичен для систем типов Unix в том смысле, что он применяется только тогда, когда символ новой строки является просто символом новой строки. Не ясно, что это применимо здесь. Кроме того, предупреждение кажется бесполезным, если файл состоит только из пустой строки. Однако я избегаю Stackoverflow, потому что люди часто понижают голос без объяснения причин.
Есть одна вещь, которую я не вижу в предыдущих ответах. Предупреждение об отсутствии конца строки может быть предупреждением, когда часть файла была усечена. Это может быть признаком отсутствия данных.
Мне сложно правильно слить в ветки. Кажется, что у ветвей есть проблемы с окончанием строки, потому что, когда я открываю окно конфликта в Visual Studio, оно показывает 0 конфликтов и 0 различий между многочисленными файлами.
Я добавил файл gitattributes в обе ветки, который просматривает и выполняет обновить репозиторий в обоих репозиториях.
Когда я обновился в обоих репозиториях не было изменений для фиксации, даже несмотря на то, что в инструкциях говорилось, что будут изменения для фиксации (по сути, изменения связаны с преобразованиями EOL).
Вот мои gitattributes
Я также проверил и мои глобальные core.autocrlf равно true (поскольку все наши разработчики используют Visual Studio в Windows)
Файл .git / config (не включая ссылки на ветки)
Я в своем уме, прохожу бесчисленные ТАК вопросы / ответы - гуглил, безрезультатно - мое количество конфликтов продолжает расти.
Также обратите внимание: я использую GIT в TFS - не уверен, что это изменит ситуацию.
ОБНОВЛЕНИЕ 1: Я скопировал упомянутые «конфликтующие» два файла из Visual Studio, каждый в свои собственные окна Notepad ++ с включенным «показывать символы -> показывать конец строки» - затем я сравнил оба «конфликтующих» файла, и, как вы можете видеть, НЕТ разницы в окончаниях строк (оба файла содержат одинаковые CR / LF, как показано на изображении ниже) - поэтому я предполагаю, что VS выполняет преобразование EOL или что-то в этом роде? ИЛИ, когда я копирую его в Notepad ++, он выполняет какое-то преобразование EOL? Не уверен, что это вообще помогает.
Я использую Visual Studio 2015 с обновлением 3
Обновление 2: Я добавил это удобное End of Line Extension Visual Studio, которое показывает файлы Символы EOL, чтобы я мог видеть все символы EOL прямо на экране слияния / сравнения, и, похоже, они точно совпадают между файлами.
Вот мастер (слияние с мастером ПРИМЕЧАНИЕ: этот файл является CRLF ПЕРЕД слиянием, после слияния CRLF должны быть преобразованы в LF):
Вот из чего я выполняю слияние:
Какую версию Visual Studio вы используете (включая версию обновления - например, Visual Studio 2015 с обновлением 4)? Внутри Visual Studio, если вы отключите параметр «Игнорировать обрезку пробелов», отображаются ли какие-либо изменения в различиях?
Я обновил свой вопрос своей версией Visual Studio. Также мне сложно найти это место для опции - где это?
Ошибка EF: SQLite Error 19: 'FOREIGN KEY constraint failed'
Есть следующие классы: public class AspNetUser : IdentityUser < public string? FirstName < get; set; >public string? LastName < get; set; >public Groups? GroupId < get; .
Как сделать движение фигуры в обратную сторону?
Есть программа(которую помог сделать хороший человек), где квадрат как бы сжимается до тех пор пока не станет крестом "Х", а затем он должен разжиматься обратно в квадрат и так по кругу. .
Связанные метки
Site design / logo © 2022 Stack Exchange Inc; user contributions licensed under cc by-sa. rev 2022.5.10.42086
Нажимая «Принять все файлы cookie» вы соглашаетесь, что Stack Exchange может хранить файлы cookie на вашем устройстве и раскрывать информацию в соответствии с нашей Политикой в отношении файлов cookie.
Запуск git на машине с Windows XP, используя bash. Я экспортировал свой проект из SVN, а затем клонировал пустой репозиторий.
Затем я вставил экспорт в пустой каталог репозиториев и сделал:
@apphacker, потому что стандартизация окончаний строк менее раздражает, чем необходимость изменять их самостоятельно при разграничении двух файлов. (И, конечно, если вы не согласны, вы можете отключить функцию core.autocrlf).
Я часто касаюсь множества строк, потому что я экспериментирую с разными идеями, добавляю операторы трассировки, чтобы увидеть, как они работают, и т. Д. Тогда я могу захотеть зафиксировать изменение только в двух или трех строках и заставить git полностью игнорировать другие, потому что я положил их обратно, как я их нашел (или я так думал).
@MatrixFrog: ваш редактор, кажется, не работает, не может автоматически определять окончания строк. Что он? Я работаю над гибридными проектами, которые должны иметь несколько файлов LF и некоторые другие файлы CRLF в одном репо. Не проблема для любого современного редактора. Неразбериха с управлением версиями (или передачей файлов) с окончаниями строк, чтобы обойти ограничения редактора, является худшей идеей в истории - очевидно из простой длины объяснений ниже.
Концепция autocrlf заключается в прозрачной обработке преобразования концов строк. И это делает!
Плохая новость : значение необходимо настроить вручную.
Хорошая новость : делать это нужно ОДИН раз за установку git (также возможна настройка каждого проекта).
Как autocrlf работает :
Здесь crlf = маркер конца строки в стиле win, lf = стиль unix (и mac osx).
(pre-osx cr не затронут ни для одного из трех вариантов выше)
Когда появляется это предупреждение (под Windows)
- autocrlf = true если у вас есть Unix-стиль lf в одном из ваших файлов (= RARELY),
- autocrlf = input если у вас есть win-стиль crlf в одном из ваших файлов (= почти ВСЕГДА),
- autocrlf = false - НИКОГДА!
Что означает это предупреждение
Предупреждение « LF будет заменено на CRLF » говорит о том, что вы (имея autocrlf = true ) потеряете свой LF в стиле Unix после цикла фиксации (он будет заменен CRLF в стиле Windows). Git не ожидает, что вы будете использовать LF в стиле Unix под Windows.
Предупреждение « CRLF будет заменен на LF » говорит о том, что вы (имея autocrlf = input ) потеряете свой CRLF в стиле Windows после цикла проверки-подтверждения (он будет заменен на LF в стиле Unix). Не используйте input под окнами.
Еще один способ показать, как autocrlf работает
где x - это CRLF (в стиле Windows) или LF (в стиле Unix), а стрелки обозначают
Значение по умолчанию для core.autocrlf выбирается во время установки git и сохраняется в общесистемной gitconfig ( %ProgramFiles(x86)%\git\etc\gitconfig ). Также есть (каскадирование в следующем порядке):
- «глобальный» (для пользователя) gitconfig, расположенный в ~/.gitconfig , еще один
- «глобальный» (для пользователя) gitconfig в $XDG_CONFIG_HOME/git/config или $HOME/.config/git/config и
- «локальный» (для репо) gitconfig в .git/config в рабочем каталоге .
Итак, напишите git config core.autocrlf в рабочем каталоге, чтобы проверить текущее используемое значение и
Предупреждения
- git config настройки могут быть изменены gitattributes настройками.
- crlf -> lf преобразование происходит только при добавлении новых файлов, crlf файлы, уже существующие в репо, не затрагиваются.
Мораль (для Windows):
- использовать core.autocrlf =, true если вы планируете использовать этот проект также под Unix (и не хотите настраивать ваш редактор / IDE для использования концов строк Unix),
- использовать core.autocrlf =, false если вы планируете использовать этот проект только под Windows ( или вы настроили свой редактор / IDE для использования концов строк Unix),
- никогда не используйте core.autocrlf =, input если у вас нет веских причин ( например, если вы используете утилиты Unix под Windows или если у вас возникают проблемы с makefiles),
PPS Мое личное предпочтение - настройка редактора / IDE для использования окончаний в стиле Unix и настройка core.autocrlf на false .
При этом git diff он говорит: «В конце файла нет новой строки» .
Хорошо, нет новой строки в конце файла. Подумаешь?
Возможно, если у вас есть файл, который заканчивается без новой строки, и вы добавляете еще одну строку, git должен будет показать, что предыдущая последняя строка изменилась, так как он включает символ новой строки как часть строки?
Это указывает на то, что '\n' в конце файла нет новой строки (обычно это также CR или CRLF).
То есть, проще говоря, последний байт (или байты, если вы работаете в Windows) в файле не является новой строкой.
Обратите внимание, что это хороший стиль - всегда ставить символ новой строки как последний символ, если это разрешено форматом файла. Кроме того, например, для заголовочных файлов C и C ++ это требуется стандартом языка.
Из любопытства, можете ли вы объяснить, почему считается хорошим стилем всегда ставить символ новой строки в качестве последнего символа? Редактировать: нашел это обсуждение .
@Joe Это не имеет особого смысла. Новая строка - это новая строка , т.е. разделитель между строками, а не конец строки. У нас нет символов начала строки, потому что они не нужны. У нас нет символов конца строки по той же причине.
@ Acjay Я утверждаю, что между "Разделителем между строками" и "концом строки" по сути лучше. Ни одно из представлений не является правильным или неправильным, просто один из способов взглянуть на это. Я предлагаю, чтобы мы продолжали использовать точку зрения, которая исторически практична, так как мы уже делаем это таким образом, и это имеет смысл, когда вы принимаете это. Последовательность важна. Нет необходимости ломать это в названии точки зрения «разделитель между строками».
@WORMSS «Новое для меня» - это не то же самое, что «новое соглашение». Это подобно открытию любого другого соглашения о программировании. Вы просто идете с этим. Вы можете отклониться, но вы только изолируете себя. (Или в этом случае, фактически ломая инструменты.) Подумайте о том, сколько других открыло какое-то соглашение Rails или PEP8, и насколько согласованно эти сообщества остались в целом, потому что они сдались - несмотря на то, что написали код наоборот.
Это не просто плохой стиль, это может привести к неожиданному поведению при использовании других инструментов в файле.
В последней строке нет символа новой строки. Посмотрим, сколько строк в файле:
Может быть, это то, что вы хотите, но в большинстве случаев вы, вероятно, ожидаете, что в файле будет 2 строки.
Кроме того, если вы хотите объединить файлы, они могут вести себя не так, как вы ожидаете:
Наконец, если вы добавите новую строку, ваши различия будут немного более шумными. Если вы добавили третью строку, она показала бы редактирование второй строки, а также новое добавление.
Результат cat в порядке, но параметр wc "-l, --lines" неверен. Даже в руководстве написано «печатать количество строк», а не «печатать количество строк».
@wget Я нахожусь на util-linux 2.34, и это может подтвердить, что этот ответ описывает текущее поведение. Я предполагаю, что ваш редактор добавил символ "\ n".
Единственная причина в том, что исторически Unix имел соглашение о всех читаемых человеком текстовых файлах, заканчивающихся символом новой строки. В то время это позволило избежать дополнительной обработки при отображении или объединении текстовых файлов и избежать обработки текстовых файлов иначе, чем файлов, содержащих другие виды данных (например, необработанные двоичные данные, которые не читаются человеком).
Из-за этого соглашения многие инструменты той эпохи ожидают окончания новой строки, в том числе текстовые редакторы, инструменты сравнения и другие инструменты обработки текста. Mac OS X была построена на BSD Unix, а Linux был разработан для совместимости с Unix, поэтому обе операционные системы унаследовали одно и то же соглашение, поведение и инструменты.
Windows не была разработана, чтобы быть Unix-совместимой, поэтому она не имеет того же соглашения, и большинство программ для Windows будут работать без всяких запаздываний.
Но, так как Git был разработан для Linux впервые, и многие программы с открытым исходным кодом построены на Unix-совместимых системах, таких как Linux, Mac OS X, FreeBSD и т. Д., Большинство сообществ с открытым исходным кодом и их инструменты (включая языки программирования) продолжаются следовать этим соглашениям.
Есть технические причины, которые имели смысл в 1971 году, но в эту эпоху это в основном соглашение и поддержание совместимости с существующими инструментами.
Если вы добавите новую строку текста в конец существующего файла, который еще не имеет newline character , diff будет показывать старую последнюю строку как измененную, даже если концептуально это не так.
Это как минимум одна веская причина, чтобы добавить newline character в конце.
Читайте также: