Jump to content

[1.11] Install App


Recommended Posts

Download


Introduction

The Install App workflow speeds installation process (or rather copy) of applications downloaded outside of Mac App Store. The workflow is completely written using Bash Script.

How it works?

There are two ways to invoke that workflow:

  • through keyword — install — which shows all eligible files/packages (.app package, .zip archive, .dmg image and .pkg installer) found in specified folder (default is ~/Downloads) and copy, run, mount or extract them dependably of what kind of file/package we choose; you can also use install name so Alfred will narrow results;

pqFNwSM.jpg

I4j76AO.jpg

  • through File Action Install App which behave in similar way as above.

2iaeN3N.jpg

The Install App workflow behaves as follow:

  • if you choose .app package it will be copied to /Applications folder;
  • if you choose .pkg file it will be opened;
  • if you choose .dmg file it will be mounted and searched for .app or .pkg to copy or run them; at the end the image will be unmounted;
  • if you choose .zip file it will be unzipped into folder which will be searched for .app, .pkg or .dmg to copy, run or mount them; at the end the temp folder will be deleted;
  • at the end of whole process you will be asked if you want to remove the source file.

Tips

  • to change folder to search for mentioned files you need to edit Script Filter element of workflow → uncomment SEARCHDIR variable and edit its value

Release info

 

1.11:

  • improve mounting dmg files – now works with images with EULA

 

1.10:

  • displays app icon if user has that app already (eligible for app updates files)

 

1.9:

  • bug fixes
  • dramatically reduces workflow size (from ~700 KB to 150 KB)
  • workflow now searches in subdirectories of main directory
  • if workflow finds .app package it will display that app's real icon (not a placeholder)

1.8:

  • bug fixes
  • following last update the workflow will open installed application if it was opened

1.7:

  • workflow checks now if app is already running and if so it asks to quit it

1.6:

  • fixed file matching
  • fixed post-install notifications

1.5:

  • unmount .dmg image after copying/installing app,
  • remove temporary .zip folder after copying/installing app,
  • ability to remove source files after copying/installing app (the dialog window will appear).

1.3

  • initial public release.

Thanks

I would like to thank Franz Greiling who inspired me to make this workflow with his own version.

Edited by Maciej Skrzypczak
Link to comment

Great, it's working now :-)

 

I have some feedback for you though:

Screen%20Shot%202015-04-20%20at%2011.38.

In the above picture, you can see your own workflow, and actual app (pacapong.app), a hidden R history file ".Rapp.history" (this is a software used in research for statistical analysis and the likes), and a folder "71135_katapult_zip" containing blender models, images and html files.

 

I don't really think ".Rapp.history" and "71135_katapult_zip" have their place on this list. If you don't want to filter files by their extension, then at least you could try and explore them and see if they fit (the ".Rapp" file will not have the usual package content structure, the "katapult_zip" is actually a folder containing nothing that can be installed).

 

My Download is not so very messy. It is, but I think it could be way worse, in which case I'd be lost in files suggested for install...

 

Anyway, I like what you did ;-)

Link to comment

Great, it's working now :-)

 

I have some feedback for you though:

Screen%20Shot%202015-04-20%20at%2011.38.

In the above picture, you can see your own workflow, and actual app (pacapong.app), a hidden R history file ".Rapp.history" (this is a software used in research for statistical analysis and the likes), and a folder "71135_katapult_zip" containing blender models, images and html files.

 

I don't really think ".Rapp.history" and "71135_katapult_zip" have their place on this list. If you don't want to filter files by their extension, then at least you could try and explore them and see if they fit (the ".Rapp" file will not have the usual package content structure, the "katapult_zip" is actually a folder containing nothing that can be installed).

 

My Download is not so very messy. It is, but I think it could be way worse, in which case I'd be lost in files suggested for install...

 

Anyway, I like what you did ;-)

 

 

Actually my workflow should filter files by their extension but in some circumstances it seems that it is not doing this properly. I will certainly look for solution for that issue. Thank you Florian for pointing that out!

Link to comment

That's great idea! But how to make it? ;)

 

It would be easy for .app apps but what about other types – .zip, .dmg and .pkg? :)

No idea, sorry. Either these won't have a cool icon or maybe some already existing code out there can help you with this. But I have personally no idea.

 

I was also thinking that you might want to do a deeper search, find apps in folders within the Download folder, that'd be cool too.

Link to comment

No idea, sorry. Either these won't have a cool icon or maybe some already existing code out there can help you with this. But I have personally no idea.

 

I was also thinking that you might want to do a deeper search, find apps in folders within the Download folder, that'd be cool too.

 

I will look for a way to find the solution for app icons.

 

Also thanks for idea to make deeper search. I'll definetely add this! :)

Link to comment

You seem to be developing this workflow pretty actively so I'll keep inputting: when dealing with .app files, why copy them and not move them? Then you wouldn't need to close the app first, and the user wouldn't have (albeit temporarily) twice the app on their computer... This happened to me this morning :-)

Link to comment

1.9 update is here and contains:

  • bug fixes
  • dramatically reduces workflow size (from ~700 KB to 150 KB)
  • workflow now searches in subdirectories of main directory
  • if workflow finds .app package it will display that app's real icon (not a placeholder)

I have updated my first post with download links:

Link to comment

No idea, sorry. Either these won't have a cool icon or maybe some already existing code out there can help you with this. But I have personally no idea.

 

I was also thinking that you might want to do a deeper search, find apps in folders within the Download folder, that'd be cool too.

 

You seem to be developing this workflow pretty actively so I'll keep inputting: when dealing with .app files, why copy them and not move them? Then you wouldn't need to close the app first, and the user wouldn't have (albeit temporarily) twice the app on their computer... This happened to me this morning :-)

 

So I did successfully added ability to search subdirectories also. :) As well as „moving” .app packages which means it is still copied to /Applications folder but then the source file is deleted without prompt. The "cp" or "mv" commands are not so reliable as "rsync" command is (that I use) and that is why I decided to leave it as is only with mentioned addition – removing .app package.

 

Now the app icons in resluts: I did get managed how to display app's icon if it is found in source directory (which also let's me to drastically reduce size of whole workflow), but I still did not solved how to add icons corresponding to apps inside of .zip, .dmg and .pkg files. But I will work on that. ;)

Edited by Maciej Skrzypczak
Link to comment

The "cp" or "mv" commands are not so reliable as "rsync" command is.

 

Ok so then here's an idea: you `rsync` a temporary copy of the file, you `mv` the file, and then delete the temp copy. Then you don't need to close the app (except if the `mv` failed but then it'll only be rare cases). If the `mv` failed, you have the backup temp copy to start the process over.

Link to comment

Ok so then here's an idea: you `rsync` a temporary copy of the file, you `mv` the file, and then delete the temp copy. Then you don't need to close the app (except if the `mv` failed but then it'll only be rare cases). If the `mv` failed, you have the backup temp copy to start the process over.

 

Okay, to be clear, to know if I understand you. :) What you suggest is to copy app using `rsync` into temporary folder and then move it into /Applications folder in place of old app?

 

If so, there are my thoughts: 1) you can not use `mv` command to replace existing folder. It works only if the folder exists but in other cases it will move new folder INTO old one. I could also mv just the contents of new folder into old one, so you will end up with old and new files and in some cases it can brake the app I think. 2) I do not think replacing app if it is already opened is safe and I would not want cause that someone would lose his files. Due to SSD popularity closing app, replacing it with `rsync` and open it up again takes just seconds but you will be sure that it all was made in safe way. :)

 

If you think that I am exaggerating and there is no risk into replacing new app with old one I can search solutions using other languages (AppleScript, Python, etc.). :)

 

Anyway thank you one more time for spending time on my workflow and made it better by providing such excellent feedback. :)

Link to comment

Not what I meant at all.

 

Here it is:

  1. Create a BACKUP version of the app you want to install with the safe `rsync` method
  2. Try and `mv` the ORIGINAL app into /Applications
  3. Delete the BACKUP

If `mv` worked, then you didn't need to close the app, this is ideal. If it didn't, then you had a backup copy to `rsync` into \Applications (in which case you will have to ask to close the app). But with this process, closing the app is only required rarely.

Link to comment
  • 3 weeks later...

Great!

 

For those of us who like to keep our apps organized in folders, what about implementing a way to search for whether the app already exists in a subfolder in /Applications, and then moving the update to that same folder?

 

Paul

Link to comment

For those of us who like to keep our apps organized in folders, what about implementing a way to search for whether the app already exists in a subfolder in /Applications, and then moving the update to that same folder?

 

Thank you Paul for feedback. I will try to implement that. Stay tuned. :)

Link to comment
  • 2 weeks later...
  • 6 years later...

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...