но ошибок может быть много, не?

А мне нравится, что нет isfileexists. Нафиг лишнее действие? Сразу говоришь, 'открой файл'. А если его нет, или еще какая то беда, тогда отлавливаешь ошибку.

А если мне нужно проверить только наличие файла?

Ну и отлично. видишь ошибку. Мне кажется это лучше, чем isfileexist, isfilereadonly, isfileчтототам

А если нужно просто проверить наличие файла, то чтото неверно в постановке задачи ?

А если нужно просто проверить наличие файла, то чтото неверно в постановке задачи ?

Например, нужно откопировать файлы из одного каталога в другой. Если файл в целевом каталоге существует, НЕ перезаписывать его.

Сэкономлю аж 2 строчки при юзании isFileExist ?

а то, что round нет?

а то, что round нет?

но будет же

Я бы попросил это сделать оболочку )

Например, нужно откопировать файлы из одного каталога в другой. Если файл в целевом каталоге существует, НЕ перезаписывать его.

if _, err := os.Stat("/path/to/file"); !os.IsNotExist(err) { printf("File doesn't exist"); } Вполне достточно

if _, err := os.Stat("/path/to/file"); !os.IsNotExist(err) { printf("File doesn't exist"); } Вполне достточно

Выше писал, что решение есть, но оно не красивое.

Выше писал, что решение есть, но оно не красивое.

в красивом будет другой метод?

в красивом будет другой метод?

В красивом будет os.IsFileExists(filename) bool

В красивом будет os.IsFileExists(filename) bool

Does

Выше писал, что решение есть, но оно не красивое.

ну напиши свою либу utils и используй во всех проектах)

В красивом будет os.IsFileExists(filename) bool

filePath := "/path/to/file" if !os.Stat(filePath) { printf("File doesn't exist"); } file, err := os.Open(filePath) if err != nil { panic(err) } или filePath := "/path/to/file" file, err := os.Open(filePath) if err != nil { panic(err) } я правда не понимаю, в чем смысл)

error все равно будет

ну вставь switch если хочешь обработать отдельно, все равно лучше не будет

Смысл в том, что сразу понятно назначение кода.

ну заменишь _, err := os.Stat("/path/to/file"); !os.IsNotExist(err) на isExist("...") Сильно читаемость повысится?

if все равно останется, будет лишь немного короче

Смысл в том, что сразу понятно назначение кода.

дай пример кода, правда

дай пример кода, правда

if !os.IsFileExists("file.txt") { fmt.Println("Файл не существует") }

if !os.IsFileExists("file.txt") { fmt.Println("Файл не существует") }

doesFileExist тогда уж

ну заменишь _, err := os.Stat("/path/to/file"); !os.IsNotExist(err) на isExist("...") Сильно читаемость повысится?

Читаемость лучше на ~50%, судя по длине строки ))

if !os.IsFileExists("file.txt") { fmt.Println("Файл не существует") }

думаешь чего больше, кейсов, когда надо проверить , есть ли файл или тех, где потом с ним надо работать?

думаешь чего больше, кейсов, когда надо проверить , есть ли файл или тех, где потом с ним надо работать?

Это плохой принцип не писать тот код, что редко используется.

Это плохой принцип не писать тот код, что редко используется.

дело в том, что код для второго случая покрывает первый

дело в том, что код для второго случая покрывает первый

Зачем тогда в пакете есть os.Create, когда его покрывает os.OpenFile?

Зачем тогда в пакете есть os.Create, когда его покрывает os.OpenFile?

не знаю, может потому что его чаще используют?

Зачем тогда в пакете есть os.Create, когда его покрывает os.OpenFile?

загляни в create он вызывает openfile func Create(name string) (*File, error) { return OpenFile(name, O_RDWR|O_CREATE|O_TRUNC, 0666) }

он про это и говорит

загляни в create он вызывает openfile func Create(name string) (*File, error) { return OpenFile(name, O_RDWR|O_CREATE|O_TRUNC, 0666) }

Я в курсе. Вопрос в том, что для одного случая есть сахар, для другого - нет.

его метод Exists тоже будет вызывать`Open`

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

разве нет?

Я в курсе. Вопрос в том, что для одного случая есть сахар, для другого - нет.

в случае создания не нужно париться на счет прав и флагов. А вот проверка выполняется и без сахары просто

Короче вот тут мнение разраба https://stackoverflow.com/questions/12518876/how-to-check-if-a-file-exists-in-go [...] It's not actually needed very often and [...] using os.Stat is easy enough for the cases where it is required.

Тогда остаётся вопрос, почему нету функции простого копирования файлов.

ну он как раз пишет, что это никто не использует

Тогда остаётся вопрос, почему нету функции простого копирования файлов.

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

Короче вот тут мнение разраба https://stackoverflow.com/questions/12518876/how-to-check-if-a-file-exists-in-go [...] It's not actually needed very often and [...] using os.Stat is easy enough for the cases where it is required.

так себе отговорка а потом почти у каждого вариации на тему func IsExists(path string) bool { if _, err := os.Stat(path); os.IsNotExist(err) { return false } return true }

так себе отговорка а потом почти у каждого вариации на тему func IsExists(path string) bool { if _, err := os.Stat(path); os.IsNotExist(err) { return false } return true }

просто return , без if)

даже ой

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

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

но с ос статс как-то через чур

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

А если файлы надо просто копировать/перемещать без открытия?

А если файлы надо просто копировать/перемещать без открытия?

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

юзай команды bash

там и го не нужен для просто скопировать

А если файлы надо просто копировать/перемещать без открытия?

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

из го вызывать команды bash)

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

os.Copy(dst, src string) error

А если файлы надо просто копировать/перемещать без открытия?

для перемещения есть os.Rename

для перемещения есть os.Rename

Не работает, если нужно переместить между разными носителями (например, из tmpfs на диск).

os.Copy(dst, src string) error

а реализацию то)

ребят, а вы еще продолжаете?))) третий час подходит к концу

скучно (

а реализацию то)

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

ребят, а вы еще продолжаете?))) третий час подходит к концу

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

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

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

Вот по поводу перемещения https://github.com/golang/go/issues/13766

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

На что я парирую, что os.OpenFile тоже годится и для создания файла, и для открытия. Но для них написаны os.Create и os.Open соответственно.

Ладно, я что-то устал ))

На что я парирую, что os.OpenFile тоже годится и для создания файла, и для открытия. Но для них написаны os.Create и os.Open соответственно.

на что я сошлюсь на ответ контрибьютера про частоту использования

да

на что я сошлюсь на ответ контрибьютера про частоту использования

который довольно очевиден хз

на частоту сферических коней в ваккууме

на что я сошлюсь на ответ контрибьютера про частоту использования

Наверно исследование они провели ))

в баре с шмузи

Наверно исследование они провели ))

чтобы узнать, что в детроите воняет, не надо туда ездить)

провели точно хорошо время

На что я парирую, что os.OpenFile тоже годится и для создания файла, и для открытия. Но для них написаны os.Create и os.Open соответственно.

выше писал

в случае создания не нужно париться на счет прав и флагов. А вот проверка выполняется и без сахары просто

в случае создания не нужно париться на счет прав и флагов. А вот проверка выполняется и без сахары просто

> в случае создания не нужно париться В винде да. В линуксе не соглашусь.

> в случае создания не нужно париться В винде да. В линуксе не соглашусь.

С чем не согласишься? Cо своим доводом? Create дефолтный только есть, с параметрами по умолчанию Нужен наверно еще такой?) func Create(name string, flag int, perm FileMode) (*File, error) { return OpenFile(name, flag, perm) }

а что с виндой не так?

ругнуться на отсутствие прав и она может

а что с виндой не так?

с ней все не так

ой, всё! (с)

ага да

делаю простой DI типа того, как описано в этой статье https://appliedgo.net/di/. если у меня все в разных пакетах, то куда будет по фень-шую засунуть интерфейс? т.е. пакет А с методом М1 требует интерфейс И1. структура с методом, который его реализует, находится в пакете Б. интерфейс надо куда класть? в А, Б или третий пакет?

поясни, не хочу додумывать, что ты имел в виду

что значит "пакет требует", кого реализовывает?

поясни, не хочу додумывать, что ты имел в виду

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

субъективный вопрос

ну вот мне интересно, кто как думает

если все остальное в разных пакетах - то в отдельный пакет, если они все в одном пакете - то в тот же пакет

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

хочешь узнать кто как бы сделал, озвучь конкретный кейс

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

> представь, что Poem, Notebook и Napkin в разных пакетах это не имеет смысла

я бы положил все это в 1 пакет

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

зависит от контекста

чо это? а если у меня много кода и клиенты к разным системам?

чо это? а если у меня много кода и клиенты к разным системам?

кейс конкретный дай