This looks great. Is there a streamlined install for Ubuntu?
Facebook PathPicker
21–30 of 168 posts
Re: Facebook PathPicker
#22This looks great. Is there a streamlined install for Ubuntu?
In the meantime you can try the manual installation method listed in the README: https://github.com/facebook/pathpicker/
@itsbits Why do you say that? curious if you found anything
Re: Facebook PathPicker
#23This looks great. Is there a streamlined install for Ubuntu?
@andyl We are working on getting a linuxbrew recipe working. There's shouldn't be anything blocking this from working on linux systems (assuming Python 2.7 is installed). In the meantime you can try the manual installation method listed in the README: https://github.com/facebook/pathpicker/ @itsbits Why do you say that? curious if you found anything
$ sudo git clone git@github.com:facebook/PathPicker.git
Cloning into 'PathPicker'...
Permission denied (publickey).
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
Any ideas? Thanks.EDIT: Nevermind. It's an issue with using sudo to git. I can use my own account, but I can't do it in /usr/local.
Re: Facebook PathPicker
#24(Same works for URLs, with the default browser)
Re: Facebook PathPicker
#25I'm joking, and this looks neat, but the optimal solution is almost certainly to keep your hands on the keyboard while in the shell.
Re: Facebook PathPicker
#26Hey everyone, I'm in the main engineer on this project if anyone has questions. Facebook has a large codebase, so naturally we have a lot of long filenames and paths. It's a pain to type these out by hand, so I'd see a lot of (new) engineers select the text with their mouse before pasting it into the command line. This is pretty inefficient and I knew there had to be a better way, so a few of us started hacking on a…
Thanks for establishing something that embraces this.
Re: Facebook PathPicker
#27Hey everyone, I'm in the main engineer on this project if anyone has questions. Facebook has a large codebase, so naturally we have a lot of long filenames and paths. It's a pain to type these out by hand, so I'd see a lot of (new) engineers select the text with their mouse before pasting it into the command line. This is pretty inefficient and I knew there had to be a better way, so a few of us started hacking on a…
What did the more experienced engineers do differently?
Re: Facebook PathPicker
#28Hey everyone, I'm in the main engineer on this project if anyone has questions. Facebook has a large codebase, so naturally we have a lot of long filenames and paths. It's a pain to type these out by hand, so I'd see a lot of (new) engineers select the text with their mouse before pasting it into the command line. This is pretty inefficient and I knew there had to be a better way, so a few of us started hacking on a…
> so I'd see a lot of (new) engineers select the text with their mouse What did the more experienced engineers do differently?
Re: Facebook PathPicker
#29One of the best little-known features of iTerm2 is Semantic History. Cmd-click on filenames and they will be opened by the default application (or you can configure an action to be performed). It's working directory aware and works great with all output. I connected it to Sublime and it even works with line numbers. (Same works for URLs, with the default browser)
Re: Facebook PathPicker
#30Hey everyone, I'm in the main engineer on this project if anyone has questions. Facebook has a large codebase, so naturally we have a lot of long filenames and paths. It's a pain to type these out by hand, so I'd see a lot of (new) engineers select the text with their mouse before pasting it into the command line. This is pretty inefficient and I knew there had to be a better way, so a few of us started hacking on a…
Oh wow, thanks! I was just thinking about this today - how I'm always cut-and-pasting file paths from ag (silver surfer) results at the console. One thing I noticed: FPP gets confused by filenames with multiple dots. If a file is named for example "dev_backup.ldif.gz", FPP thinks that "ldif.gz" is the entire file name.
For instance, we currently match on "add/remove" output from git status which is less than fortunate. For performance reasons we don't actually go check if each of those files exists (since sometimes you want to pipe hundreds of results into fpp [EDIT: and are using an expandrive or network mount])