Allow specifying command as an argument to fpp about pathpicker

[pcottle]

Hrm I'm not sure of the benefits here -- you'll have to type git add either way (using the UI vs command line mode), and with our better alias support (coming soon) the command mode will be even more powerful.

how would this help your workflow @xatnys ?

[xatnys]

Indeed, this is more convenience / desired workflow than an outright improvement. There's a simplicity to splitting the workflow into two steps; something like this:

• enter command pipeline: foo | bar | fpp
• select files -> ENTER

So, at least to me, it seems like it'd be more natural to fit in applying commands in the first step rather than after the file selection process. I'm not sure what the alias support specifically entails, but I suppose I'm looking to be able to create some specialized fpp aliases. I can hack around it by abusing $EDITOR so this is certainly not imperative. I'm currently doing this:
function fpp-add { EDITOR='git add' fpp }

[pcottle]

Ahh hrmmm, yeah this is fairly legitimate. Let me keep this open for now, I do agree adding a bunch of aliases would be nice.

Also keep in mind that we have FPP_EDITOR bash variable which can be used instead of EDITOR, but a command line arg is even better

[webglider]

@pcottle having this feature will also greatly help people who want to write scripts which use fpp. An example would be a script which downloads a set of zip files into a folder cds into it and pipes an ls into fpp allowing the user to select some of the zip files after which it would automatically unzip them or do something like that. Now to achieve this kind of functionality fpp has to have the option of passing commands to be executed as parameters (in this case the unzip command)

[pcottle]

Ooooh that's a pretty sweet workflow @webglider, never thought about fpp as being a step in some totally different workflow / script.

Alright you guys convinced me, ill add this right after I merge some of this UI testing work

[lastquestion]

I have a PR half in flight on this one if you haven't started yet @pcottle which i was gonna try and finish tonight

[pcottle]

Alright go for it @lastquestion ! It might require some rebasing after I land some of the testing infra but we can see what it looks like when yours goes up :D

[lastquestion]

did you decide on a testing infra? prob unittest because it's built into python and wouldn't require a dependecy?

[pcottle]

Oh yeah @lastquestion I meant the dependency injection we have to do in order to test the curses UI. Its not really "infra" or a dependency but a fair refactor of the UI code. However I got it working in 7753a73

Basically then ScreenForTest can record the output of the curses commands and produce some actual expected output which we can record and test against. then we can add test cases for things like #92 and test on all versions of python too

unittest was gonna be used regardless

[lastquestion]

oic that's good approach. the mock is nice, also would be super sweet to have a built in logging to stderr or whatever that we can use while dev. I use sys.stderr.write and then remove it when i commit, but a general purpose logger would be useful

[lastquestion]

if we are gonna stick with unittest i'll write some unit tests for the color stuff after the test stuff lands also.

[pcottle]

also would be super sweet to have a built in logging to stderr or whatever that we can use while dev. I use sys.stderr.write and then remove it when i commit, but a general purpose logger would be useful

yeah we dont have general purpose logging, but you might also want to look at from output import debug which does a similar thing! thats what i use rather than stderr

[lastquestion]

Fixed in #99

[pcottle]

yeah i think this should work! #99 and my followups got the majority of it, but I do think we should prevent command mode if you have a preset command...

[christylewis1978-36]

Stay off my account

On Wednesday, May 13, 2015, Lin Xu [email protected] wrote:

oic that's good approach. the mock is nice, also would be super sweet to
have a built in logging to stderr or whatever that we can use while dev. I
use sys.stderr.write and then remove it when i commit, but a general
purpose logger would be useful

—
Reply to this email directly or view it on GitHub
#72 (comment).