История изменений

В чём идея Golang и UNIX-овых бинарников в целом?

Go — язык программирования.

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

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

Такая программа уже есть: rm doks.png

Я нажал [TAB], но вместо привычного терминального выбора близлежащего файла у меня сработал длинный перенос строки.

Терминальный выбор делает сторонняя хрень readline. Не рекомендую отвлекаться на механизм её работы. Достаточно того, что чтение stdin не подразумевает никаких readline или прочей интерактивности, просто поток байт.

И это не перенос строки, а отступ. Перенос строки — это что-то из line feed, carriage return или enter.

Ни .Appimage, ни .x86_64(как делает Godot). Это натолкнуло меня на мысль, что я неправильно понимаю идею Golang.

AppImage — способ распространения программ.

Что такое x86_64 в контексте Godot я не знаю, но x86_64 — это архитектура процессора, соответственно, скорее всего, Godot собрал исполняемый файл под x86_64. go build, внезапно, делает тоже самое.

Почитав где-то на Хабре про сборку пакетов, я увидел упоминания о go install, где предлагалось инсталлировать пакеты в папку установки языка, куда-то тоже в раздел с бинарниками.

go install — способ установить чужую программу. А свою программу куда хочешь клади или устанавливай.

Это натолкнуло меня на другую мысль - а может Golang нужен, чтобы писать на нём какие-то демоны или или какие-то кусочки бэкенда в стиле «работает - не трогай»?

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

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

Куда положишь свою программу — там она и будет лежать. Хочешь /bin/hello, хочешь /usr/john/hello, хочешь C:\Program Files\My Hello World\Hello.exe.

Для вызова из текущей директории достаточно ./hello, для вызова из другой директории — абсолютный или относительный путь.

Запуск по названию файла никак на это не влияет. Это просто шорткат, алиас, «Иван» вместо «Иван Иванович Иванов». Это реализовано с помощью решения (скорее костыля, но не важно), единого для винды и юниксов — переменной окружения PATH.

В чём идея Golang и UNIX-овых бинарников в целом?

Go — язык программирования.

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

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

Такая программа уже есть: rm doks.png

Я нажал [TAB], но вместо привычного терминального выбора близлежащего файла у меня сработал длинный перенос строки.

Терминальный выбор делает сторонняя хрень readline. Не рекомендую отвлекаться на механизм её работы. Достаточно того, что чтение stdin не подразумевает никаких readline или прочей интерактивности, просто поток байт.

Ни .Appimage, ни .x86_64(как делает Godot). Это натолкнуло меня на мысль, что я неправильно понимаю идею Golang.

AppImage — способ распространения программ.

Что такое x86_64 в контексте Godot я не знаю, но x86_64 — это архитектура процессора, соответственно, скорее всего, Godot собрал исполняемый файл под x86_64. go build, внезапно, делает тоже самое.

Почитав где-то на Хабре про сборку пакетов, я увидел упоминания о go install, где предлагалось инсталлировать пакеты в папку установки языка, куда-то тоже в раздел с бинарниками.

go install — способ установить чужую программу. А свою программу куда хочешь клади или устанавливай.

Это натолкнуло меня на другую мысль - а может Golang нужен, чтобы писать на нём какие-то демоны или или какие-то кусочки бэкенда в стиле «работает - не трогай»?

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

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

Куда положишь свою программу — там она и будет лежать. Хочешь /bin/hello, хочешь /usr/john/hello, хочешь C:\Program Files\My Hello World\Hello.exe.

Для вызова из текущей директории достаточно ./hello, для вызова из другой директории — абсолютный или относительный путь.

Запуск по названию файла никак на это не влияет. Это просто шорткат, алиас, «Иван» вместо «Иван Иванович Иванов». Это реализовано с помощью решения (скорее костыля, но не важно), единого для винды и юниксов — переменной окружения PATH.

В чём идея Golang и UNIX-овых бинарников в целом?

Go — язык программирования.

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

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

Такая программа уже есть: rm doks.png

Я нажал [TAB], но вместо привычного терминального выбора близлежащего файла у меня сработал длинный перенос строки.

Терминальный выбор делает сторонняя хрень readline. Не рекомендую отвлекаться на механизм её работы. Достаточно того, что чтение stdin не подразумевает никаких readline или прочей интерактивности, просто поток байт.

Ни .Appimage, ни .x86_64(как делает Godot). Это натолкнуло меня на мысль, что я неправильно понимаю идею Golang.

AppImage — способ распространения программ.

Что такое x86_64 в контексте Godot я не знаю, но x86_64 — это архитектура процессора, соответственно, скорее всего, Godot собрал исполняемый файл под x86_64. go build, внезапно, делает тоже самое.

Почитав где-то на Хабре про сборку пакетов, я увидел упоминания о go install, где предлагалось инсталлировать пакеты в папку установки языка, куда-то тоже в раздел с бинарниками.

go install — способ установить чужую программу. А свою программу куда хочешь клади или устанавливай.

Это натолкнуло меня на другую мысль - а может Golang нужен, чтобы писать на нём какие-то демоны или или какие-то кусочки бэкенда в стиле «работает - не трогай»?

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

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

Куда положишь свою программу — там она и будет лежать. Хочешь /bin/hello, хочешь /usr/john/hello, хочешь C:\Program Files\My Hello World\Hello.exe.

Для вызова из текущей директории достаточно ./hello, для вызова из другой директории — абсолютный или относительный путь.

Запуск по названию файла никак на это не влияет. Это просто шорткат, алиас, «Иван» вместо «Иван Иванович Иванов». Это реализовано с помощью решения (скорее костыля, но не важно), одинакового для винды и юниксов — переменной окружения PATH.

В чём идея Golang и UNIX-овых бинарников в целом?

Go — язык программирования.

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

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

Такая программа уже есть: rm doks.png

Я нажал [TAB], но вместо привычного терминального выбора близлежащего файла у меня сработал длинный перенос строки.

Терминальный выбор делает сторонняя хрень readline. Не рекомендую отвлекаться на механизм её работы. Достаточно того, что чтение stdin не подразумевает никаких readline или прочей интерактивности, просто поток байт.

Ни .Appimage, ни .x86_64(как делает Godot). Это натолкнуло меня на мысль, что я неправильно понимаю идею Golang.

AppImage — способ распространения программ.

Что такое x86_64 в контексте Godot я не знаю, но x86_64 — это архитектура процессора, соответственно, скорее всего, Godot собрал исполняемый файл под x86_64. go build, внезапно, делает тоже самое.

Почитав где-то на Хабре про сборку пакетов, я увидел упоминания о go install, где предлагалось инсталлировать пакеты в папку установки языка, куда-то тоже в раздел с бинарниками.

go install — способ установить чужую программу. А свою программу куда хочешь клади или устанавливай.

Это натолкнуло меня на другую мысль - а может Golang нужен, чтобы писать на нём какие-то демоны или или какие-то кусочки бэкенда в стиле «работает - не трогай»?

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

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

Куда положишь свою программу — там она и будет лежать. Хочешь /bin/hello, хочешь /usr/john/hello, хочешь C:\Program Files\My Hello World\Hello.exe.

Для вызова из текущей директории достаточно ./hello, для вызова из другой директории — абсолютный или относительный путь.

Запуск по названию файла никак на это не влияет. Это просто шорткат, алиас, «Иван» вместо «Иван Иванович Иванов».

В чём идея Golang и UNIX-овых бинарников в целом?

Go — язык программирования.

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

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

Такая программа уже есть: rm doks.png

Я нажал [TAB], но вместо привычного терминального выбора близлежащего файла у меня сработал длинный перенос строки.

Терминальный выбор делает сторонняя хрень readline. Не рекомендую отвлекаться на механизм её работы. Достаточно того, что чтение stdin не подразумевает никаких readline или прочей интерактивности, просто поток байт.

Ни .Appimage, ни .x86_64(как делает Godot). Это натолкнуло меня на мысль, что я неправильно понимаю идею Golang.

AppImage — способ распространения программ.

Что такое x86_64 в контексте Godot я не знаю, но x86_64 — это архитектура процессора, соответственно, скорее всего, Godot собрал исполняемый файл под x86_64. go build, внезапно, делает тоже самое.

Почитав где-то на Хабре про сборку пакетов, я увидел упоминания о go install, где предлагалось инсталлировать пакеты в папку установки языка, куда-то тоже в раздел с бинарниками.

go install — способ установить чужую программу. А свою программу куда хочешь клади или устанавливай.

Это натолкнуло меня на другую мысль - а может Golang нужен, чтобы писать на нём какие-то демоны или или какие-то кусочки бэкенда в стиле «работает - не трогай»?

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

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

Куда положишь свою программу — там она и будет лежать. Хочешь /bin/hello, хочешь /home/user/hello, хочешь C:\Program Files\My Hello World\Hello.exe.

Для вызова из текущей директории достаточно ./hello, для вызова из другой директории — абсолютный или относительный путь.

Запуск по названию файла никак на это не влияет. Это просто шорткат, алиас, «Иван» вместо «Иван Иванович Иванов».

В чём идея Golang и UNIX-овых бинарников в целом?

Go — язык программирования.

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

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

Такая программа уже есть: rm doks.png

Я нажал [TAB], но вместо привычного терминального выбора близлежащего файла у меня сработал длинный перенос строки.

Терминальный выбор делает сторонняя хрень readline. Не рекомендую отвлекаться на механизм её работы. Достаточно того, что чтение stdin не подразумевает никаких readline или прочей интерактивности, просто поток байт.

Ни .Appimage, ни .x86_64(как делает Godot). Это натолкнуло меня на мысль, что я неправильно понимаю идею Golang.

AppImage — способ распространения программ.

Что такое x86_64 в контексте Godot я не знаю, но x86_64 — это архитектура процессора, соответственно, скорее всего, Godot собрал исполняемый файл под x86_64. go build, внезапно, делает тоже самое.

Почитав где-то на Хабре про сборку пакетов, я увидел упоминания о go install, где предлагалось инсталлировать пакеты в папку установки языка, куда-то тоже в раздел с бинарниками.

go install — способ установить чужую программу. А свою программу куда хочешь клади или устанавливай.

Это натолкнуло меня на другую мысль - а может Golang нужен, чтобы писать на нём какие-то демоны или или какие-то кусочки бэкенда в стиле «работает - не трогай»?

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

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

Куда положишь свою программу — там она и будет лежать. Хочешь /bin/hello, хочешь /home/user/hello, хочешь C:\Program Files\My Hello World\Hello.exe.

Для вызова из текущей директории достаточно ./hello, для вызова из другой директории — абсолютный или относительный путь.

Запуск по названию файла никак на это не влияет. Это просто шорткат, алиас, «Иван» вместо «Иван Иванович Иванов».

В чём идея Golang и UNIX-овых бинарников в целом?

Go — язык программирования.

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

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

Такая программа уже есть: rm doks.png

Я нажал [TAB], но вместо привычного терминального выбора близлежащего файла у меня сработал длинный перенос строки.

Терминальный выбор делает сторонняя хрень readline. Не рекомендую отвлекаться на механизм её работы. Достаточно того, что чтение stdin не подразумевает никаких readline или прочей интерактивности, просто поток байт.

Ни .Appimage, ни .x86_64(как делает Godot). Это натолкнуло меня на мысль, что я неправильно понимаю идею Golang.

AppImage — способ распространения программ.

Что такое x86_64 в контексте Godot я не знаю, но x86_64 — это архитектура процессора, соответственно, скорее всего, Godot собрал исполняемый файл под x86_64. go build, внезапно, делает тоже самое.

Почитав где-то на Хабре про сборку пакетов, я увидел упоминания о go install, где предлагалось инсталлировать пакеты в папку установки языка, куда-то тоже в раздел с бинарниками.

go install — способ установить чужую программу. А свою программу куда хочешь клади или устанавливай.

Это натолкнуло меня на другую мысль - а может Golang нужен, чтобы писать на нём какие-то демоны или или какие-то кусочки бэкенда в стиле «работает - не трогай»?

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

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

Куда положишь свою программу — там она и будет лежать. Хочешь /bin/hello, хочешь /home/user/hello, хочешь C:\Program Files\My Hello World\Hello.exe.

Для вызова из текущей директории достаточно ./hello, для вызова из другой директории — абсолютный или относительный путь.

Запуск по названию файла никак на это не влияет. Это просто шорткат, алиас, «Иван» вместо «Иван Иванович Иванов».