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

When packaging a shoes app you should be able to specify if it should launch with shoes or cshoes. #110

Closed
kvberge opened this Issue Apr 8, 2015 · 22 comments

Comments

Projects
None yet
3 participants
@kvberge

kvberge commented Apr 8, 2015

It would be nice to have, for example, a Windows executable (generated using the shoes package system) to execute with a console. I have an app that I set to run with cshoes.exe (instead of shoes.exe) and it would be nice to be able to build that into the executable so users can run the *.exe and get the console output.

@ccoupe ccoupe added the Windows label Apr 8, 2015

@ccoupe

This comment has been minimized.

Show comment
Hide comment
@ccoupe

ccoupe Apr 8, 2015

Contributor

@kvberge - thanks for filling the request. Are you using the Shoes GUI to package or driving it with the command line (cshoes.exe --ruby ). The later is easier to add platform specific options to otherwise you'll have to wait for the mysterious much delayed advanced installer option.

Contributor

ccoupe commented Apr 8, 2015

@kvberge - thanks for filling the request. Are you using the Shoes GUI to package or driving it with the command line (cshoes.exe --ruby ). The later is easier to add platform specific options to otherwise you'll have to wait for the mysterious much delayed advanced installer option.

@kvberge

This comment has been minimized.

Show comment
Hide comment
@kvberge

kvberge Apr 8, 2015

@ccoupe, I was using the Shoes GUI to package and create the *.exe. I was unaware that you could drive it from the command line...care to provide some details on how to do that (or point me to the documentation or something to read myself)? I would much prefer the command line installation method over the GUI any day...

Just to be clear, the behavior I'm looking for is the same as when you run cshoes.exe application.shoes (I name my shoes apps *.shoes) so that when running I can output some messages in the console vs running shoes.exe application.shoes (no console output).

kvberge commented Apr 8, 2015

@ccoupe, I was using the Shoes GUI to package and create the *.exe. I was unaware that you could drive it from the command line...care to provide some details on how to do that (or point me to the documentation or something to read myself)? I would much prefer the command line installation method over the GUI any day...

Just to be clear, the behavior I'm looking for is the same as when you run cshoes.exe application.shoes (I name my shoes apps *.shoes) so that when running I can output some messages in the console vs running shoes.exe application.shoes (no console output).

@ccoupe ccoupe added the Normal label Apr 9, 2015

@ccoupe

This comment has been minimized.

Show comment
Hide comment
@ccoupe

ccoupe Apr 9, 2015

Contributor

I've now added an incomplete wiki article - https://github.com/Shoes3/shoes3/wiki/Command-line-packager - it's got the clues you need.

The option to use cshoes.exe instead of shoes.exe has to be passed into the the stub as a resource string (and id #) and the stub.c modified to read the resource and of course we'll need a new build of Shoes and lots of testing. It's pretty ugly down in stub.c land and the Tax Man approaches so it may take a while to implement.

It's a very reasonable request. You distribute a long running Shoes based app which may be inflicted with puts and C printf's that your user may want to monitor. Understood. I like working on user suggestions and I'm happy to know that folks are attempting to use the packager functionality.

Contributor

ccoupe commented Apr 9, 2015

I've now added an incomplete wiki article - https://github.com/Shoes3/shoes3/wiki/Command-line-packager - it's got the clues you need.

The option to use cshoes.exe instead of shoes.exe has to be passed into the the stub as a resource string (and id #) and the stub.c modified to read the resource and of course we'll need a new build of Shoes and lots of testing. It's pretty ugly down in stub.c land and the Tax Man approaches so it may take a while to implement.

It's a very reasonable request. You distribute a long running Shoes based app which may be inflicted with puts and C printf's that your user may want to monitor. Understood. I like working on user suggestions and I'm happy to know that folks are attempting to use the packager functionality.

@ccoupe ccoupe self-assigned this Apr 9, 2015

ccoupe added a commit that referenced this issue Apr 11, 2015

for #110 - cmd line driven packaging can have a console window if asked.
* parse --console switch to main.skel. Spawn console. Windows only!
* still has some debugging output to launch console
* mods to pass the switch from packshoes thru to the packaged app.

@ccoupe ccoupe added this to the 3.2.23 milestone Apr 11, 2015

@ccoupe

This comment has been minimized.

Show comment
Hide comment
@ccoupe

ccoupe Apr 11, 2015

Contributor

@kvberge , I've got something working that might satisfy your request. Basically it adds a --console switch to the shoes.exe and cshoes.exe command line processing (Windows only) and the voodoo to pass that into the packaged app. It does require a new version of Shoes be installed and that Shoes version needs to be used to package via your command line: opts['winargs'] = '--console'

If you're willing to test it, uninstall your current shoes and download 3.2.23 from the beta site http://walkabout.mvmanila.com/public/shoes. Download the little isp.exe app which does write to the console as it pings an IP number. Actually that isp.exe will download the Shoes 3.2.23 from the beta site if you don't have Shoes installed. Enabling the console option from the gui will have to wait for more important bug fixes.

Let us know what you think.

Contributor

ccoupe commented Apr 11, 2015

@kvberge , I've got something working that might satisfy your request. Basically it adds a --console switch to the shoes.exe and cshoes.exe command line processing (Windows only) and the voodoo to pass that into the packaged app. It does require a new version of Shoes be installed and that Shoes version needs to be used to package via your command line: opts['winargs'] = '--console'

If you're willing to test it, uninstall your current shoes and download 3.2.23 from the beta site http://walkabout.mvmanila.com/public/shoes. Download the little isp.exe app which does write to the console as it pings an IP number. Actually that isp.exe will download the Shoes 3.2.23 from the beta site if you don't have Shoes installed. Enabling the console option from the gui will have to wait for more important bug fixes.

Let us know what you think.

ccoupe added a commit that referenced this issue Apr 11, 2015

@ccoupe

This comment has been minimized.

Show comment
Hide comment
@ccoupe

ccoupe Apr 11, 2015

Contributor

I added a make_shy method to PackShoes - it took a lot longer than 20 minutes but I'm kind of clueless. I also updated https://github.com/Shoes3/shoes3/wiki/Command-line-packager to describe the obvious to me settings.

Contributor

ccoupe commented Apr 11, 2015

I added a make_shy method to PackShoes - it took a lot longer than 20 minutes but I'm kind of clueless. I also updated https://github.com/Shoes3/shoes3/wiki/Command-line-packager to describe the obvious to me settings.

@kvberge

This comment has been minimized.

Show comment
Hide comment
@kvberge

kvberge Apr 11, 2015

@ccoupe, I will try this out as soon as I get some free time! Thank you so much for your effort!

kvberge commented Apr 11, 2015

@ccoupe, I will try this out as soon as I get some free time! Thank you so much for your effort!

@ccoupe

This comment has been minimized.

Show comment
Hide comment
@ccoupe

ccoupe Apr 20, 2015

Contributor

@kvberge - any update?

Contributor

ccoupe commented Apr 20, 2015

@kvberge - any update?

@kvberge

This comment has been minimized.

Show comment
Hide comment
@kvberge

kvberge Apr 20, 2015

@ccoupe, sorry I've been busy with work lately...I'll make time to test this in the next day or so.

kvberge commented Apr 20, 2015

@ccoupe, sorry I've been busy with work lately...I'll make time to test this in the next day or so.

@kvberge

This comment has been minimized.

Show comment
Hide comment
@kvberge

kvberge Apr 20, 2015

@ccoupe, I receive the following error when I try to package my *.shy file.

C:/Program Files (x86)/Shoes/lib/shoes/packshoes.rb:25:in 'dnlif_exe': uninitialized constant PackShoes::DIR (NameError) from test.rb:22:in '<main>'

I can't debug that further due to time restraints, but maybe you have a quick pointer as to what the issue might be.

kvberge commented Apr 20, 2015

@ccoupe, I receive the following error when I try to package my *.shy file.

C:/Program Files (x86)/Shoes/lib/shoes/packshoes.rb:25:in 'dnlif_exe': uninitialized constant PackShoes::DIR (NameError) from test.rb:22:in '<main>'

I can't debug that further due to time restraints, but maybe you have a quick pointer as to what the issue might be.

@ccoupe

This comment has been minimized.

Show comment
Hide comment
@ccoupe

ccoupe Apr 20, 2015

Contributor

did you run the command cshoes.exe --ruby test.rb ? it looks like Shoes isn't initialized or you ran it with regular ruby?

Contributor

ccoupe commented Apr 20, 2015

did you run the command cshoes.exe --ruby test.rb ? it looks like Shoes isn't initialized or you ran it with regular ruby?

@kvberge

This comment has been minimized.

Show comment
Hide comment
@kvberge

kvberge Apr 21, 2015

@ccoupe, you're right...I didn't run it with cshoes.exe --ruby. That appears to have generated an exe. When I run the app.exe, it pops open with a console! Success.

I do have other questions, though. When I run the app.exe it generates another file named --console app.shy, what's this file for? This file is not present when using the shoes GUI to generate the exe (the one that doesn't get the console). Also, maybe I'm mis-remembering, but I thought the executable could be run w/o the *.shy file being present. Is that not true? Also, the message Using new console /path/to/shoes.exe app.shy would be better if it wasn't there :)

These are really nit-picky gripes and are not going to stop me from using what you've provided.

kvberge commented Apr 21, 2015

@ccoupe, you're right...I didn't run it with cshoes.exe --ruby. That appears to have generated an exe. When I run the app.exe, it pops open with a console! Success.

I do have other questions, though. When I run the app.exe it generates another file named --console app.shy, what's this file for? This file is not present when using the shoes GUI to generate the exe (the one that doesn't get the console). Also, maybe I'm mis-remembering, but I thought the executable could be run w/o the *.shy file being present. Is that not true? Also, the message Using new console /path/to/shoes.exe app.shy would be better if it wasn't there :)

These are really nit-picky gripes and are not going to stop me from using what you've provided.

@ccoupe

This comment has been minimized.

Show comment
Hide comment
@ccoupe

ccoupe Apr 21, 2015

Contributor

Yes, there is some debugging output that needs to be removed . --console is the command line option to cshoes .exe to spawn the new console. There shouldn't be a file named that. Window title maybe but not a file. - does it have text in it?

Normally the shy.rb is expanded (into AppData\Local) every time the app.exe is run. It should go away after the app finishes - possible bug if it doesn't.

Be aware that you're app.exe downloads from the beta site and not the main shoes site so you don't want to distribute too far and wide least someone ends up with a beta that doesn't work.

Glad it works (mostly OK). Thanks for the follow up.

Contributor

ccoupe commented Apr 21, 2015

Yes, there is some debugging output that needs to be removed . --console is the command line option to cshoes .exe to spawn the new console. There shouldn't be a file named that. Window title maybe but not a file. - does it have text in it?

Normally the shy.rb is expanded (into AppData\Local) every time the app.exe is run. It should go away after the app finishes - possible bug if it doesn't.

Be aware that you're app.exe downloads from the beta site and not the main shoes site so you don't want to distribute too far and wide least someone ends up with a beta that doesn't work.

Glad it works (mostly OK). Thanks for the follow up.

@kvberge

This comment has been minimized.

Show comment
Hide comment
@kvberge

kvberge Apr 23, 2015

@ccoupe, when I run the app.exe it does, in fact, create a file name --console app.shy. This 'file' appears to be a copy of the app.shy file. It has the same file size as the stand-alone app.shy that I created via the command line. So, I have 3 files now app.shy, app.exe, and --console app.shy. The latter file is only created when the app.exe is executed. It is not auto-deleted. However, as you say, in the TEMP directory, the app is expanded and removed upon app.exe finish. So that looks okay. The only issue is this mysterious --console app.shy file that gets created (in the same root as the exe).

Also, is there way to generate the app.exe without the need to have the app.shy file distributed with it? It seems that if I remove the app.shy file from the root directory of the app.exe, the shoes app fails to open with the error message 'cannot open /path/to/application/app.shy'. I though the purpose of the app.exe was to make it a single, distributable package? Maybe I'm wrong?

Thanks for your hard work! (I'll revert back to the last stable release if/when I distribute my software).

kvberge commented Apr 23, 2015

@ccoupe, when I run the app.exe it does, in fact, create a file name --console app.shy. This 'file' appears to be a copy of the app.shy file. It has the same file size as the stand-alone app.shy that I created via the command line. So, I have 3 files now app.shy, app.exe, and --console app.shy. The latter file is only created when the app.exe is executed. It is not auto-deleted. However, as you say, in the TEMP directory, the app is expanded and removed upon app.exe finish. So that looks okay. The only issue is this mysterious --console app.shy file that gets created (in the same root as the exe).

Also, is there way to generate the app.exe without the need to have the app.shy file distributed with it? It seems that if I remove the app.shy file from the root directory of the app.exe, the shoes app fails to open with the error message 'cannot open /path/to/application/app.shy'. I though the purpose of the app.exe was to make it a single, distributable package? Maybe I'm wrong?

Thanks for your hard work! (I'll revert back to the last stable release if/when I distribute my software).

@ccoupe

This comment has been minimized.

Show comment
Hide comment
@ccoupe

ccoupe Apr 24, 2015

Contributor

Kevin, the Shoes packaging goal is (mostly) about installing Shoes on a system and then running a script or shy.rb Just little things to share with friends and coworkers. Basically if every had Shoes installed then all you to update and pass around is a shy. Packaging a real honest to god Windows app like the NSIS installer creates is not a Shoes packaging goal. The term packaging means too many things (all different).

One can do things to help hide Shoes for a more commercial look or purpose: Clone the project and build Shoes from source. Replace the shoes icons with ones to match your design, you'll need to change some values in the rakefile so the NSIS script uses your app name (and icons) and you'll need to package with your private shoes included rather than downloading the normal Shoes (risking that might happen) @BackOrder has done it for an app he distributes for Windows and OSX. We've modified some of the Shoes build infrastructure to accommodate that type of packaging but it's a long ways from 'general purpose' for Windows, the OSX part is minimal but it doesn't much help here and the Linux part is almost impossible because the current choice is to install Shoes in a user directory without requiring admin privileges and registering with all the linux distro maintainers.

I'll dig into why there is the mysterious --console app.shy is being created.

Contributor

ccoupe commented Apr 24, 2015

Kevin, the Shoes packaging goal is (mostly) about installing Shoes on a system and then running a script or shy.rb Just little things to share with friends and coworkers. Basically if every had Shoes installed then all you to update and pass around is a shy. Packaging a real honest to god Windows app like the NSIS installer creates is not a Shoes packaging goal. The term packaging means too many things (all different).

One can do things to help hide Shoes for a more commercial look or purpose: Clone the project and build Shoes from source. Replace the shoes icons with ones to match your design, you'll need to change some values in the rakefile so the NSIS script uses your app name (and icons) and you'll need to package with your private shoes included rather than downloading the normal Shoes (risking that might happen) @BackOrder has done it for an app he distributes for Windows and OSX. We've modified some of the Shoes build infrastructure to accommodate that type of packaging but it's a long ways from 'general purpose' for Windows, the OSX part is minimal but it doesn't much help here and the Linux part is almost impossible because the current choice is to install Shoes in a user directory without requiring admin privileges and registering with all the linux distro maintainers.

I'll dig into why there is the mysterious --console app.shy is being created.

@ccoupe

This comment has been minimized.

Show comment
Hide comment
@ccoupe

ccoupe Apr 24, 2015

Contributor

@kvberge - can you share the little script your using to create the app.exe - email ccoupe@cableone.net if you want to keep it private.

Contributor

ccoupe commented Apr 24, 2015

@kvberge - can you share the little script your using to create the app.exe - email ccoupe@cableone.net if you want to keep it private.

@BackOrder

This comment has been minimized.

Show comment
Hide comment
@BackOrder

BackOrder Apr 24, 2015

Collaborator

I wrote a few rake tasks to package a fully deployable executable file for Windows. They create a temp directory with the Shoes app and its resources, use a custom shy packager (@ccoupe made sure it is now easy to use programmatically), edicon.exe from Ocra (https://github.com/larsch/ocra) to inject an icon into shoes.exe or cshoes.exe, and a custom NSIS installer that creates a shortcut to call Shoes with the generated shy file.

Collaborator

BackOrder commented Apr 24, 2015

I wrote a few rake tasks to package a fully deployable executable file for Windows. They create a temp directory with the Shoes app and its resources, use a custom shy packager (@ccoupe made sure it is now easy to use programmatically), edicon.exe from Ocra (https://github.com/larsch/ocra) to inject an icon into shoes.exe or cshoes.exe, and a custom NSIS installer that creates a shortcut to call Shoes with the generated shy file.

@kvberge

This comment has been minimized.

Show comment
Hide comment
@kvberge

kvberge Apr 24, 2015

@ccoupe, do you mean the script that I use as the input to cshoes.exe --ruby? Or the whole project (all the ruby files)? Also, I think I understand better now the packaging goals of Shoes. I'm certainly not trying to make more work for you, passing around the shy file is OK in my situation. I was looking for obfuscation from my source code when sharing my app and I think the shy file will be good enough...it's certainly better than placing all my source code on the destination machine. A nicely packaged exe would be nice, but it's not something that I'm going to lose sleep over (and I don't want you to lose any either!). Considering the machines I'm installing it on have Shoes installed already will make the shy file enough. L

@BackOrder, I'll have to check out Ocra and find some time to try it out. Thanks!

kvberge commented Apr 24, 2015

@ccoupe, do you mean the script that I use as the input to cshoes.exe --ruby? Or the whole project (all the ruby files)? Also, I think I understand better now the packaging goals of Shoes. I'm certainly not trying to make more work for you, passing around the shy file is OK in my situation. I was looking for obfuscation from my source code when sharing my app and I think the shy file will be good enough...it's certainly better than placing all my source code on the destination machine. A nicely packaged exe would be nice, but it's not something that I'm going to lose sleep over (and I don't want you to lose any either!). Considering the machines I'm installing it on have Shoes installed already will make the shy file enough. L

@BackOrder, I'll have to check out Ocra and find some time to try it out. Thanks!

@ccoupe

This comment has been minimized.

Show comment
Hide comment
@ccoupe

ccoupe Apr 25, 2015

Contributor

@kvberge - just that little script to do the packag step with $ cshoes.exe --ruby this-script

Even when fully packaged and customized exe like @BackOrder produces, the shy inside is expanded into the temp space which the app runs. In case you haven't thought of it yet - any file in there that is created or updated by you app won't be there on the next execution of the exe/shy so you'll have to pick a different directory for settings files or databases, output files...

Contributor

ccoupe commented Apr 25, 2015

@kvberge - just that little script to do the packag step with $ cshoes.exe --ruby this-script

Even when fully packaged and customized exe like @BackOrder produces, the shy inside is expanded into the temp space which the app runs. In case you haven't thought of it yet - any file in there that is created or updated by you app won't be there on the next execution of the exe/shy so you'll have to pick a different directory for settings files or databases, output files...

@kvberge

This comment has been minimized.

Show comment
Hide comment
@kvberge

kvberge May 2, 2015

@ccoupe , my apologies for how long this took...here's what the script looks like:

require 'shoes/packshoes'
opts = {}
opts['app'] = /path/to/my/app.shy
opts['dnlhost'] = 'shoes.mvmanilla.com'
opts['dnlpath'] = '/public/select/win32.rb'
opts['relname'] = 'federales'
opts['winargs'] = '--console'

PackShoes.dnlif_exe opts

I mostly used your example, and maybe that's where I was wrong.

One other, unrelated thing I noticed, is that Time.now appears to return the incorrect time (well wrong timezone and therefore time).

> cshoes.exe --ruby -e "puts Time.now"
2015-05-02 01:35:56 +0000

The +0000, should be -0400 and the time should be adjusted accordingly. Can you give any insight into that? Thanks!

edit I should add that I'm using the following version of shoes:
Shoes federales 3.2.22 r1933 i386-mingw32 2.1.5

kvberge commented May 2, 2015

@ccoupe , my apologies for how long this took...here's what the script looks like:

require 'shoes/packshoes'
opts = {}
opts['app'] = /path/to/my/app.shy
opts['dnlhost'] = 'shoes.mvmanilla.com'
opts['dnlpath'] = '/public/select/win32.rb'
opts['relname'] = 'federales'
opts['winargs'] = '--console'

PackShoes.dnlif_exe opts

I mostly used your example, and maybe that's where I was wrong.

One other, unrelated thing I noticed, is that Time.now appears to return the incorrect time (well wrong timezone and therefore time).

> cshoes.exe --ruby -e "puts Time.now"
2015-05-02 01:35:56 +0000

The +0000, should be -0400 and the time should be adjusted accordingly. Can you give any insight into that? Thanks!

edit I should add that I'm using the following version of shoes:
Shoes federales 3.2.22 r1933 i386-mingw32 2.1.5

@ccoupe

This comment has been minimized.

Show comment
Hide comment
@ccoupe

ccoupe May 2, 2015

Contributor

@kvberge

To do the packaging with the --console feature you must be running 3.2.23 (the beta) and the machine that app.exe runs on must be using 3.2.23

I see another problem. opts['dnlhost'] = 'shoes.mvmanilla.com' has to be opts['dnlhost'] = 'walkabout.mvmanilla.com' because the that's where the beta of Shoes 3.2.23 is kept which has the --console feature that app.exe (when packaged and installed ON A FRESH SYSTEM).

To do the packaging with the --console feature you must be running 3.2.23 (the beta) and the machine that app.exe runs on must be using 3.2.23 or have no Shoes at all.

I've filed a bug #123 for the timezone problem.

Contributor

ccoupe commented May 2, 2015

@kvberge

To do the packaging with the --console feature you must be running 3.2.23 (the beta) and the machine that app.exe runs on must be using 3.2.23

I see another problem. opts['dnlhost'] = 'shoes.mvmanilla.com' has to be opts['dnlhost'] = 'walkabout.mvmanilla.com' because the that's where the beta of Shoes 3.2.23 is kept which has the --console feature that app.exe (when packaged and installed ON A FRESH SYSTEM).

To do the packaging with the --console feature you must be running 3.2.23 (the beta) and the machine that app.exe runs on must be using 3.2.23 or have no Shoes at all.

I've filed a bug #123 for the timezone problem.

@kvberge

This comment has been minimized.

Show comment
Hide comment
@kvberge

kvberge May 2, 2015

@ccoupe, I should've been more clear; I was using using the 3.2.23 beta version you supplied earlier when running that packaging script. I wasn't sure about the dnl options since I had shoes installed (and it's installed on the PC where the software is going to be run) so I didn't modify them.

I switched to 3.2.22 to illustrate the Time.now issue.

kvberge commented May 2, 2015

@ccoupe, I should've been more clear; I was using using the 3.2.23 beta version you supplied earlier when running that packaging script. I wasn't sure about the dnl options since I had shoes installed (and it's installed on the PC where the software is going to be run) so I didn't modify them.

I switched to 3.2.22 to illustrate the Time.now issue.

@ccoupe

This comment has been minimized.

Show comment
Hide comment
@ccoupe

ccoupe May 22, 2015

Contributor

@kvberge - I haven't forgotten (just busy). I've recreated your problem. It appears that when shoes extracts the payload (script or shy) on a --console packaged app, it names it '--console your-script.rb' or '--console your-shy.shy'. While working on a different bug a few days ago, I found that ruby and the command line args on Windows can not be modified like I thought. That may not be the problem here but it's a starting point.

Contributor

ccoupe commented May 22, 2015

@kvberge - I haven't forgotten (just busy). I've recreated your problem. It appears that when shoes extracts the payload (script or shy) on a --console packaged app, it names it '--console your-script.rb' or '--console your-shy.shy'. While working on a different bug a few days ago, I found that ruby and the command line args on Windows can not be modified like I thought. That may not be the problem here but it's a starting point.

@ccoupe ccoupe closed this in 3781623 May 23, 2015

@ccoupe ccoupe referenced this issue Jun 16, 2015

Closed

Branch 'console' #127

ccoupe added a commit that referenced this issue Jul 6, 2015

Fixes #135 and #110
* Use Separate path to temp and for cmdline args.

ccoupe added a commit that referenced this issue Jul 6, 2015

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