Hacker Newsnew | past | comments | ask | show | jobs | submit | bazurbat's commentslogin

Yes you can. One vault at a time. Exporting other metadata apart from basic name, password, url is very clunky. Then you will also need to manually handle attachments for each entry. Some types of entries also have "special needs". Then sometimes there are errors. I've recently migrated from 1P and it was a lot of tedious manual work. It feels like the support for exporting data is kinda neglected, so I'm glad I did it while the feature is still there.

OTOH I've helped a relative to migrate from 1P to Bitwarden who had only a single vault for browser logins with name, password and url items and the process was quick and easy.


The thing I've hated from the day 1 and still can not forget is the reserving of the "type" keyword. Basically every module has these ugly "tp" or "typ" or "type_" structure members everywhere but type aliases are rarely seen in comparison.


Raw identifiers can be used to get around any reserved keyword. So r#type would be as idiomatic a workaround as any. Arguably a lot clearer than the alternatives.


Location: Łódź, PL

Remote: Yes

Willing to relocate: Yes

Technologies: Linux, Android, C, C++, Lua, Scheme, Bash, some Java and others

Résumé/CV: https://stackoverflow.com/cv/bazurbat

Email: [email protected]

I am a versatile engineer with more than 10 years of industry experience in different domains mostly focusing on embedded Linux as of late. I have an extensive team leading experience and have seen through multiple projects going to production from start to finish.


Location: Lodz, Poland

Remote: maybe

Willing to relocate: yes

Technologies: C, C++, Lua, Scheme, some Rust, Linux (driver and embedded firmware development), Android

Résumé/CV: https://stackoverflow.com/cv/bazurbat

Email: bazurbat(at)gmail(dot)com

I am a versatile and goal-oriented professional with more than 10 years of total industry experience starting from system administrator and going through quality assurance engineer to senior developer positions. I have seen through multiple projects going to production an led developer teams in diverse domains and environments such as financial, medical and automotive.


Isn't it just repeats the command 5 times instead of retrying?

IMO Bash with it's multitude of annoying quoting and field splitting rules, many irrelevant features focusing on interactive use, and error handling as an afterthought is just wrong choice for writing robust systems. It's too easy to make mistakes. And it still works only in the simplest cases, until somebody evil deliberately pass you newline delimited string or something with patterns which expands in unexpected place, etc. Properly handling those cases will make your script ugly mess. Actually I find the mental burden when writing shell scripts is very akin to programming in C.


> Bash with it's multitude of annoying quoting and field splitting rules

So don't use the Bourne Again shell. After all and to start with, if you live in the Debian or Ubuntu worlds, your van Smoorenburg rc scripts have not been using the Bourne Again shell for about a decade.

There's no reason at all that run programs need be written in any shell script at all, let alone in the Bourne Shell script. Laurent Bercot publishes a tool named execline that takes the ideas of the old Thompson shell ("if" being an external command and so forth) to their logical conclusions, which is far better suited to what's being discussed here. One can also write run programs in Perl or Python, or write them as nosh scripts.

* http://blog.infinitenegativeutility.com/2015/2/celebrating-d...


If the command is a daemon, that's basically retrying. But if you want to check the exit code, that's easy to do inside retry().

I totally agree with your second paragraph, that is why I'm working on fixing shell :)

http://www.oilshell.org/blog/

This entry in particular is relevant to your concerns:

http://www.oilshell.org/blog/2016/11/06.html


https://github.com/bazurbat/spawn

A small script to ease chrooting (or docker running) into a development environment with usual set of workarounds (toggleable) like passing virtual filesystems, SSH/X11 env, home directory, etc.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: