На самом деле, как вы можете догадаться, мелочи вроде ref присутствуют в коде потому, что когда-то я их добавил в попытках заставить программу компилироваться, а затем не удалил. Код в целом весьма старый на самом деле — июнь.
docopt не стал пользоваться потому что показалось, что это достаточно просто сделать самому (в отличие от разбора INI). Заодно показал, как пользоваться match.
Не могу сказать, что разделяю ваши опасения по поводу его небезопасности. Тут даже sudo на весь скрипт не запрашивается — оно используется внутри, если нужно, и скрипт об этом предупреждает. Можно передать --prefix и тогда оно вообще не понадобится, просто придётся окружение трогать тогда.
Не распарсил. Так работает только на win или не работает только на win? Особенно, в контексте использования sh.
Уже написали несколько объяснений, но я попробую ещё раз, потому что про строки любят спрашивать :)
«Михаил» — это строковый литерал, это не «объект». Его нельзя изменять, например. Это «unboxed» значение, и to_string превращает его в boxed значение на куче.
Насчёт .unwrap() — в этом-то и разница. В go ошибку можно не обрабатывать и это будет невидимо в исходном коде — так же, как и в Си. В Rust не проверенная ошибка (т.е. например Result, который не используется) вызывает предупреждение компилятора, а простейший способ её не обрабатывать — .unwrap() — помечает данное место как явно не обрабатывающее ошибки.
Представьте себе, что вам нужно в проекте на go из 10000 строк найти все места, где ошибки не обрабатываются, и оценить, сколько временеи нужно будет на приделывание правильной обработки. Вам придётся делать это, вручную вычитывая код. В Rust достаточно текстового поиска.
Команда как-то «сама» собралась в репозитории. Возможно, некоторая социальность GitHub'а помогает. Кажется, я сам изначально нашёл проект, потому что кто-то в ленте его отметил.
Никакой официальной поддержки от кого-либо у нас не было. До конца довести было непросто — поначалу было больше маленьких вливаний от многих людей, ближе к концу все почти все изменения делали одни и те же люди.
К сожалению, с переводами ситуация пока не самая лучшая. Авторы знают о нашем переводе и о нескольких других, но избегают придания им статуса «официальных». Наш перевод упомянут на странице документации оригинала, но интегрировать его к себе они пока не хотят — так сказал steveklabnik, который занимается документацией проекта.
Я пока знаю, что версии для читалок для оригинала сделал другой человек сс помощью pandoc (вместо нашего calibre). К сожалению, я не видел результат и не знаю, можно ли избежать там наших проблем с EPUB.
На самом деле, как вы можете догадаться, мелочи вроде ref присутствуют в коде потому, что когда-то я их добавил в попытках заставить программу компилироваться, а затем не удалил. Код в целом весьма старый на самом деле — июнь.
docopt не стал пользоваться потому что показалось, что это достаточно просто сделать самому (в отличие от разбора INI). Заодно показал, как пользоваться match.
INI — наверное, потому, что лично мне он более знаком и кажется менее навороченным, чем TOML.
Спасибо, поправил.
«Михаил» — это строковый литерал, это не «объект». Его нельзя изменять, например. Это «unboxed» значение, и to_string превращает его в boxed значение на куче.
$ RUST_BACKTRACE=1 cargo run -- del '-1 OR 1=1' Running `target/debug/rust-phonebook del -1\ OR\ 1=1` thread '<main>' panicked at 'called `Result::unwrap()` on an `Err` value: ParseIntError { kind: InvalidDigit }', ../src/libcore/result.rs:736 stack backtrace: 1: 0x555c75a62f49 - sys::backtrace::tracing::imp::write::ha2610c4d9f39e7d20qt 2: 0x555c75a62128 - panicking::on_panic::h0137eb721b989e66zqx 3: 0x555c75a551fe - sys_common::unwind::begin_unwind_inner::h9323ab6063ed22d03es 4: 0x555c75a55998 - sys_common::unwind::begin_unwind_fmt::hd6d1e3432b74d1dc9ds 5: 0x555c75a619a1 - rust_begin_unwind 6: 0x555c75a91aff - panicking::panic_fmt::h3b414ef7ca9e7ec0wZK 7: 0x555c7586bff6 - result::Result<T, E>::unwrap::h17631234665356226696 at ../src/libcore/macros.rs:28 8: 0x555c7586ae97 - main::closure.11714 at src/main.rs:85 9: 0x555c7586ae3c - ops::impls::_&'a mut F.FnOnce<A>::call_once::h16646540071590734845 at ../src/libcore/ops.rs:1795 10: 0x555c7586ade2 - option::Option<T>::map::h18348351940653665552 at ../src/libcore/option.rs:425 11: 0x555c7586ad9c - iter::Map<I, F>.Iterator::next::h6843473521919548427 at ../src/libcore/iter.rs:1686 12: 0x555c7586aadc - vec::Vec<T>.FromIterator<T>::from_iter::h16476383075473108179 at ../src/libcollections/vec.rs:1160 13: 0x555c7586aa79 - iter::Iterator::collect::h14488226810590600205 at ../src/libcore/iter.rs:567 14: 0x555c758627f7 - main::h89fbfb3db45c0143MAa at src/main.rs:84 15: 0x555c75a64b94 - sys_common::unwind::try::try_fn::h5089277237340746579 16: 0x555c75a61808 - __rust_try 17: 0x555c75a6482d - rt::lang_start::h377d03c3ab92e2f1kox 18: 0x555c758b9609 - main 19: 0x7ffb915336ff - __libc_start_main 20: 0x555c7581eaf8 - _start 21: 0x0 - <unknown>Представьте себе, что вам нужно в проекте на go из 10000 строк найти все места, где ошибки не обрабатываются, и оценить, сколько временеи нужно будет на приделывание правильной обработки. Вам придётся делать это, вручную вычитывая код. В Rust достаточно текстового поиска.
Команда как-то «сама» собралась в репозитории. Возможно, некоторая социальность GitHub'а помогает. Кажется, я сам изначально нашёл проект, потому что кто-то в ленте его отметил.
Никакой официальной поддержки от кого-либо у нас не было. До конца довести было непросто — поначалу было больше маленьких вливаний от многих людей, ближе к концу все почти все изменения делали одни и те же люди.
К сожалению, с переводами ситуация пока не самая лучшая. Авторы знают о нашем переводе и о нескольких других, но избегают придания им статуса «официальных». Наш перевод упомянут на странице документации оригинала, но интегрировать его к себе они пока не хотят — так сказал steveklabnik, который занимается документацией проекта.
Я пока знаю, что версии для читалок для оригинала сделал другой человек сс помощью pandoc (вместо нашего calibre). К сожалению, я не видел результат и не знаю, можно ли избежать там наших проблем с EPUB.