Implementing the ability to compress files/directories

[camnw]

NOTE: most recent comment has most recent update, much of this is comment is outdated

Hey, getting this here so we can work on common ground. Here is the very simple way in which I believe we should set this up. In its current state, we have some work to do with tar in specific. Here is a quick example of what happens if you try it right now with files (I compressed 3 files "a" "b" and "c" in the directory "/home/cameron/sandbox") with dmenufm and here is the result of me looking at the compressed file.

$ ls                                        
a  b  c  d  e  f  g  h  i  j  k  l  m  n  o  p  placeholder_name.tar.gz  q  r  s  t  u  v  w  x  y  z
$ tar -xzf placeholder_name.tar.gz 
$ tree
.
├── a
├── b
├── c
├── d
├── e
├── f
├── g
├── h
├── home
│   └── cameron
│       └── sandbox
│           ├── a
│           ├── b
│           └── c
├── i
├── j
├── k
├── l
├── m
├── n
├── o
├── p
├── placeholder_name.tar.gz
├── q
├── r
├── s
├── t
├── u
├── v
├── w
├── x
├── y
└── z

3 directories, 30 files

As you can see, tar does not play nicely with using absolute file paths and makes nested folders leading to the path inside of the archive. To solve this, I feel we could use the existing copy action in order to copy the files to a temporary directory ($FM_PATH/compression/?) and then just compress that directory. That will make the whole process alot smoother on our end. If you have another idea or want to continue with this let me know.

[camnw]

NOTE: Most recent comment addresses some of this, nullifying most of this comment

Most recent commit will: Copy all selected files to $FM_COMPRESSPATH

• cd to that directory and then go up one directory
• compress the directory named 'compression' (We will obviously work this out so that the user can have a custom location and this will still work)

Now, issues with this is that it puts the resulting archive in that directory we used cd to get to and also we won't be back at our previous directory. I just want to get a rough preview out of what we are doing :smiley:

[camnw]

Alright actually I thought of a better way to do this with the last commit now it will:

• cp all selected files to $FM_COMPRESSPATH
• mv $FM_COMPRESSPATH to a directory (currently named placeholder) in the current PWD
• compress this directory with tar.

So this solves some issues from before. Once we get the tar situation figured out, we can move on to the other compression formats as the rest that don't use tar are extremely similar and will likely not be that much of a hassle. Please feel free to try it out and make changes/suggestions where you see fit, as always.

[huijunchen9260]

Thank you! I would definitely check it out!

Yesterday I am implementing a new function on CMD, now you can store command like chmod +x $1, store command with $1 to tell dmenufm that there are arguments. Then dmenufm will have menu to choose file to execute this command.

Although it might be unorthodox, but I plan to call compression action ZIP, so that I can only type z and then the first action would be ZIP. If we call it CMP, then the key c will have both CMD and CMP, which might not be ideal for my design.

[camnw]

Alright. Status update, tar archiving should work pretty well with this now given you go through with it as usual. Issues that currently exist are lack of error handling and lack of making sure the user can press escape to get out of the menu without it doing the rest of the commands. In the future, when we add more compression formats that support archiving directories instead of just files, we can add to the if statement (for example, adding || echo "$compression_type" | grep "zip"; so that when compressing with zip you may select multiple files.)

[huijunchen9260]

Could you please merge the commit that I just uploaded, and simplify the code in $allselection with bulk_all_list? I think this really modulize everything in the dmenufm_action, and makes it cleaner.

[camnw]

Sure thing, will get to this tomorrow.

[camnw]

Alright. Pretty well supported now. We still need error handling and functionality to escape out of these menus. I believe you have dealt with this issue so it would help if you could apply this.

[camnw]

Haha................ may be a bit busy for a bit........ accidentally made a file called '~'.......... and then I decided to type rm -rf ~ to remove it..................... and then realized my mistake............................................. Not quite related to dmenufm, but given that I am working on this I will be less focused on contributing for a little bit cause looks like I gotta write a few files again LOL. Alot of the longer stuff is saved somewhere, so am not completely lost but still need to recover a bit...

I'll still check here so we can discuss, but not sure how much I can commit until I have a more stable environment again haha.

Take this as a good lesson and don't make the same mistake 😄

[huijunchen9260]

I feel sorry about what happened to you! Hope that you can recover your system ASAP! I think that your experience might be a good reference for next TODO in FM_NEW. Preventing users to use some shortcut when they name directories and files.

[camnw]

Haha, thanks. Won't take too long, but dang what a mistake to mkae 😆 suprised I never did this sooner.