Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Piping in a list of files #11

Open
abaldwin88 opened this issue Aug 29, 2017 · 2 comments
Open

Piping in a list of files #11

abaldwin88 opened this issue Aug 29, 2017 · 2 comments

Comments

@abaldwin88
Copy link
Owner

abaldwin88 commented Aug 29, 2017

Would it be possible to accept a list of files to move, rather than listing the current directory?
Something like find -name '*.txt' | roamer, to list files that may be deeper than the current directory?

Would require quite a bit of code restructuring... but it sounds pretty useful.

@alex-bender
Copy link
Contributor

@abaldwin88
I'd like to take this issue, but I need your assistance. Could you please describe base use-cases of this feature?
Here is what I come up with:

/path/to/a/file --> /path/to/a/main_file : rename a file
/path/to/a/file --> /path/to/file : move file to the parent directory
/one/two/three/four/file --> /one/three/four/file : create subdirs three/four under /one and move file to it

@abaldwin88
Copy link
Owner Author

@alex-bender
Ideally I'd like to keep all the functionality available to the user of a normal session. Deleting, Copying, Renaming files. Entries would be listed out using the path from the current working directory like in your example. The only real difference to the user would be that entries can include a path if they are not in the top level directory.

So I would add two things to your spec. The ability to delete an entry (file/folder) and the ability to copy an entry (file/folder).

Side Note: Being able to create nested subdirs like your example would also be excellent.

I think the trickiest part is going to be that places in the code assume that a Directory instance contains all of the valid Entry instances at a certain point in time. Since we are allowing the user to filter the list this would no longer be true. I would anticipate chunks of logic around the Directory and EditDirectory classes to be peeled off into a new class. We need to split the functionality of diffing entry changes and tracking entry paths.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants