Here what I did to encurage other people to do so in Win10 .
I uninstalled my old borked ubuntu WSL within windows programs/components and rebooted.
I opened powershell and did run: Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux to reinstall WSL and rebooted
I installed Debian from Microsoft Store.
in debian shell after setting up user and password for debian I did run: apt-get update - it was was throwing errors at me so I tried with sudo
sudo apt-get update
sudo apt-get upgrade
sudo apt-get dist-upgrade
sudo sed -i 's/stretch/buster/g' /etc/apt/sources.list
sudo apt-get update
sudo apt-get upgrade
sudo apt-get dist-upgrade
and finally
sudo apt-get install gnucobol
After this simple 12-step program I have finally GnuCOBOL 2.2 running.
cobc works, cobcrun works and GnuCOBOL has no problems to compile my source written with Notepad residing on my windows file system at c:\projekte\GnuCobol\ by accessing /mnt/c/projekte/GnuCobol.
So far so good. As long as I open a Bash shell and run from there everything works as expected.
But I want a Desktop Icon for my program. A shortcut to click on. WSL documentation states that there are two ways to do so, either using
wsl.exe "cmd to execute" or bash -C "cmd to execute"
Both work fine for build in cmds, bash-scripts, all nice.
But starting ./Hello or cobcrun ./Hello fails with
libcob: libcob.so.4: cannot open shared object file : no such file or directory
I compared what set gives and the only difference seems to be that set in bash direct gives a env-var LS_COLORS while starting from within windows it does not have the env-var LS_COLORS
where is libcob.so.4 supposed to be and what can i do to convince cobcrun to find it when called from windows via bash -C "cobcrun ./Hello" ?
Mike
Last edit: Michael Sommer 2018-06-19
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Just to verify: If you directly start the Devian environment, cd /mnt/c/projekte/GnuCobol and do cobcrun Hello this works?
Additional question: How does your compile command in NPP looks like (you compile from NPP, don't you? If not: please note the exact steps you take for compiling)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If I start a bash-shell in WSL Debian every thing works fine. cobc compiles with -m or-e, cobcrun runs a module, compiled with -e i can run it direct.
All fine.
But if I start from the windows environment bash with parameters I have a woe.
I can run bash -C "cobc -i" without problems
I can run bash -C 'ls" without problems, but
I can NOT run bash -C "/mnt/c/projekte/GnuCobol/Hello"
then I get the error about missing libcob...
so I made a small bash script
[cross]!/bin/bash
echo Hi Mike
cobcrun ./Hello
read -n 1 -s
and put that into /mnt/c/projekte/GnuCobol where I sucsessfull compiled Hello.cob resulting in Hello and Hello.so
inside bash I can call /mnt/c/projekte/GnuCobol/Test.sh it and it works. called from windows cmd or Desktop Shortcut as
bash -C "/mnt/c/projekte/GnuCobol/Test.sh"
it throws the error about not finding libcob...
WSL documentation states thas instead of calling bash -C ... I also can call wsl.exe ..., but the result is the same, ./Hello does not find libcob and cobcrun does find ./Hello but then also fails with not finding libcob.
if I put a ls in the bash script it confirmes that I am actual in the right directory. and lists Test.sh, Hello, Hello.so and Hello.cob
called from bash shell or from windows cmd/shortcut it does work and list the files, so I am at the right place..
What not work is finding libcob if called from windows cmd or shortcut using bash -C ... or wsl.exe ...
Instead of a ls I put a set there and compared the result, as stated in the first post besides missing LS_COLORS=... both results are the same.
I am pretty sure this is a simple linux issue, but I do not understand linux enough to do further trouble shooting.
So where is libcob supposed to be and what could I do to my bash script to explain to cobcrun where the library has to be searched for?
My Goal is pretty simple, I want a short-cut on the desktop to open a bash shell and start my cobol program.
I have no clue what you are saying abaut NPP
Mike
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You need to get the CMD environment set before the bash -C or add the settings to a script before launching any libcob runtime it seems.
Your shortcut icon could point to a CMD batch file, set some env vars, then invoke bash -C.
I have no clue what these settings are, but there will be hints somewhere in the WSL system.
If this were me, and I'd be doing this over and over again, I'd probably permanently set the PATH in the Windows GUI and the User Enviroment settings dialog. Or LD_LIBRARY_PATH if that is a thing in WSL space. And then forget the setting and scratch head on an unrelated problem 13 months later... :-)
If WSL supports LD_RUN_PATH, then you may be able to set all the appropriate look up directories before doing a cobc compile, and the rpath should be part of the executable.
I have docs in the FAQ about using LD_RUN_PATH on shared hosting web space systems for COBOL CGI as libcob is not normally part of hosted shells and users don't usually get root powers to be mucking around with the system directories.
Cheers,
Blue
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As allways do not assume anything. THE PROBLEM IS SOLVED.
After Step 1 and 2 I assumed that my old borked UBUNTU was gone. it was not, still there in parallel with my new Debian/testing I installed because Simon told me to do, to use Ludwigs packages.
.And guess what, the bash prompt I got when opening Bash from the Start Menu opened Bash in Debian, since new installed. And there I have GnuCOBOL 2.2.
But the Bash opened by cmd.exe and Short-Links still opened Bash on UBUNTU, my borked Version with OpenCOBOL 1.1.
Both on the same Linux/Windows File System.
So If I start my short-cuts or cmd commands with 'debian -C ...' it uses my Debian Installation and EVERYTHING WORKS.
This is so cool. With this possible we get around all the BDB/VISAM woes on windows and have a easy, and I am a Windows user - very easy way to get GnuCOBOL installed on Win 10.
The 12 step program, sounds familiar, some how, I still need to kick 03 out and add another .12.
No problem with distribution. Customer does the 12 steps, then copy my program on his windows drive sets some short-cuts and DONE. No problem with Oracle...
Super happy,
Mike
Last edit: Michael Sommer 2018-06-21
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Look for the comment from jstarks near the bottom of that ticket.
Set WSLENV to a list of environment variables that are passed through. From other reading (no testing) PATH is one of the vars. Looks like it needs a WSL build after Dec 19, 2017.
Aside:
Web servers have the same kinda issue, the CGI environment is somewhat limited (on purpose) and these kinda hints may come in handy for more than just shortcuts.
Cheers,
Blue
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This may provide some fun and gets you a little bit more comfortable with a real OS ;-)
In general I have no clue why you do all this with WSL...
Just copy the ready-to-use mingw packages (some MB) from Arnold Trembley to each system (or directly to the network share...) and simply use this from Windows instead of installing GNU/kWindows and a complete OS and doing an OS upgrade (multiple GB) on each system...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
well, I since years I am fighting with GnuCOBOL on windows. Sure the OCIDE worked well but I could not upgrade it to newer version.
all my tries with mingw and that other one ended in desaster. To complicated for me as non linux user. To easy to bork up when changing little stuff.
I am living from being a programmer and ALL of my customers need Windows Software., relay on Windows Software, use Active Directory and Policies and the Administrators are often not allowed to install Linux insted of windows, for Management reasons.
Not even as Web-Server, sad, sad, situation.
But in over 30 years of programming for my income I never had one company embracing Linux in any form. Maybe the fire-wall can run on linux, else ALL use Windows right now, on Servers and on Desktops. All of them.
But installing a Microsoft Component, named Windows Subsytem for Linux is not at all a problem with these customers and their Management, ist from Microsoft? "Yes" Ok then you can do it.
I know it is sad, but it is what it is.
The next thing is integration to the AD based Management. Once you set up the system policies in the AD right, you simply plug in a new computer and depending on the user logging in the first time, all his needed software gets installed. I have not tested this with wsl but it probabbly works like with any other Software I need to distribute to my new client-workstation, hecck it comes from the Windows Store...
Second is that it is quite invisible and sort of hidden from the end user. Not much there to fiddle with, exept some short-cuts on a network drive and a folder for the COBOL Programs. Very convient for me and my Admins.
Mike
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Haha, next step solved. Running from Network Share works
wsl automounts local drives, but no network drives.
but you can map Network drives to the drvfs shared between ww10 and linux at /mnt/xxx
So I can do:
sudo mkdir /mnt/Share .............. one time, it is persistent
sudo mount -t drvfs '\Pavillion22\Share' /mnt/Share .......... every time, not persitent.
and have my windows network drive available for the Linux Subsystem.
To make this persistend I need to modyfy /etc/bashrc.bash and add the following line at the beginning:
echo mysudopassword | sudo -S mount -t drvfs '\Pavillion22\Share' /mnt/Share
and voila ech new opened Bsh window and each Batch or Short-cut started program knows /mnt/Share. Without asking for a sudo Password.
And the credential used for accessing the network drive are the credentials from the current windows user as it should be.
This is complete seamless integration, easy to handle for Windows Admins, almost invisible to the client.
this is so nice. And ALL the goodies will work for windows user, like Brians scripting efforts, no worries on how to install RED on Windows, no need for special windows treatment,...
Mike
Last edit: Michael Sommer 2018-06-21
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You get the install steps down and get most current if you don't upgrade the underlying Debian repo (which was needed to use the currently "testing" packages) but build from source.
For this: Do only the first update + upgrade parts (may be specified on a single line, combined with && if you like to), then install the prerequistes listed in the README file via apt-get install XYZ (you may check manually on a clean installation which minimal packages you need), additional install wget, then wget the source tarball and do the tar -xf gnucobol-XYZ.tar.xz && cd gnucobol* && configure && make && make install steps. This has also the benefit that you download much less.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
My idea of using a predefined package is to avoid all of this.
As stated before this is for Windows User not at all versed in Windows itself, and for sure NOT able to install GnuCOBOL from source on Linux.
That was something even I was not able to archive yet, I know the common knowledge here is that any programmer is supposed to use linux or he is a moron, but hell then I am a moron.
But what is worse is, that the customers I have and are in need of some software I really would like to use COBOL for instead of Windows VS-Studio Applicatinos have already trouble to install Windows Programs or even Features. They are no programmer at all, they are construction worker, foremen, Plumber, Roofer, barey handling the website to put in bids for upcoming projects.
Building GnuCOL from source is simply to much to ask for. Even the current 12 step program is.
Mike
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
There are many people using GnuCOBOL that have no clue about non windows systems. (this is also shown by the downloads stars, which primarily track only windows users), don't feel bad about it.
I still would recommend anyone (including the person groups you've bored) to have a look at a free, secure and not tracking OS, not for GnuCOBOL or GNU but for their own best - but this still won't mean they must be able to do a source build - that is what distributions are for and debian does a very good job here. Thanks to Ludwin also for GnuCOBOL now.
Note: the target for WSL is officially still "a programmer that is familiar with Linux and want to use tools he knows on Windows".
People that feel themselve forced to use Windows (or force themselve to do this) need a much easier option than building a software from source and Arnolds builds provides it.
Unpack a community trusted archive and use it as a portable software, zero configuration needed.
If needed you can create your own package for tweaks or full control of the version of any program it includes. A security audit can even inspect all sources until it reaches the Windows internal dlls (try this with a MicroFocus/Fujitsu/whatever COBOL compiler / runtime).
I don't see why this should be bad in a corporate environment...
That was something even I was not able to archive yet, I know the common knowledge here is that any programmer is supposed to use linux or he is a moron, but hell then I am a moron.
Aww, that's not usually what the digs about Windows are supposed to imply, Mike. No morons. Few morons even know what GnuCOBOL is, let alone COBOL.
This isn't really supposed to come off as bad side good side.
This is ok side better side. :-)
Now, risks are up a bit. WSL is somewhat dangerous ground for long term free software growth. Part of picking up GNU/Linux is ensuring freedom, now and into how ever long it lasts, not simply smarts or level of computing aptitude. Consumers are at a disadvantage with the freedom of choice to step up to POSIX for work at this point, developers should exercise the freedoms. And then spread them.
That's the message in the medium, Mike, at least when I'm taking pokes. Paint grenades over the wall. But for a good cause.
Cheers,
Blue
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If you distrubute libcob software outside company walls then a clause in bdb licensing states need for a deal with Oracle or provide source with your binaries.
As with most things in these licensing issues, distribution of code is usually the trigger. Personal use (including a companies' personal) is personal use. Which is one of, if not thee point of free software; end user rights to modify to suit purpose. Those freedoms include no obligation to share; only obligations to not impede further freedoms, once shared.
And that was just preachy, sorry.
Anyway, just so everyone knows the implications of the official repo builds at this point, from what I've looked at so far for packaging dependencies. There are alternatives, for rebuilds.
Have good, make stuff,
Blue
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Please be more clear here. Installing a debian package fior libcob (not distributing it with the COBOL modules) at a customer side is just installing the package. As long as you ship the generated COBOL modules for use with a package I see no license issues, do you?
Additional note: as long as configure.ac is not fixed you may trap on the issue tracked with [feature-requests:#318].
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
"Our open source license is OSI-certified and permits use of Berkeley DB in open source projects or in applications that are not distributed to third parties. Our commercial license permits closed-source distribution of an application to third parties and provides business assurance."
This is an explanation. If you check the actual license this is about it is the GNU AFFERO GENERAL PUBLIC LICENSE.
Note: this only applies to more recent versions of Berkeley DB, older versions have the Sleepycat license which has different license results.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I just wanted to thank you for this thread. I hate WIndows but I am in the same situation, all of my customers run Windows. I have never seen Linux used in a laboratory, not once.
I just setup Windows 10 and I have Debain under WLS up and running now.
Hi Brian
I know what you are saying about WLS eating away at GNU but this is a path forward for me and I can encourage people to switch over to Linux if they have a cool Linux app running under Windows. This might be a good tool for evangelicals to get people to switch.
-Pat
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well, my thinking was along Simons, that when my customer installs LSW+ GnuCOBOL with BDB and I just provide my Software, I do NOT violate BDBs licencing.
If I do, then the whole thing is dead in the water.
I do understand that Brian is a evangelist, preaching freedom for software, Linux for user, etc, etc.
But this is actual the main problem I have with this. preaching freedom, but not allowing me to NOT opening my source. What freedom is this? The freedom to do as Stallman wants?
This is even worse then MS. OK I need to buy VS, but I am FREE in my decision if I provide my source or not and I can install whatever I produce on any Windows machine and - up to some point - even on Linux using Mono or Wine. Without any restrictions.
And without any licensing fees per installation.
Programming is my Job, my only means of income since 30+ years. I need to sell my software and I am neither willing not able to give it away for nothing.
As far as I can follow GnuCOBOL, ISAM/VSAM is not working correctly and no one is working on it, so to use indexed files I need to use BDB. Maybe I am wrong here but the only alternative I can see is to use ODBC, EXEC SQL and a preprocessor, destroing all the beauty of COBOLs internal filehandling.
Sad, sad, sad,
Mike
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Here what I did to encurage other people to do so in Win10 .
and finally
After this simple 12-step program I have finally GnuCOBOL 2.2 running.
cobc works, cobcrun works and GnuCOBOL has no problems to compile my source written with Notepad residing on my windows file system at c:\projekte\GnuCobol\ by accessing /mnt/c/projekte/GnuCobol.
So far so good. As long as I open a Bash shell and run from there everything works as expected.
But I want a Desktop Icon for my program. A shortcut to click on. WSL documentation states that there are two ways to do so, either using
wsl.exe "cmd to execute" or bash -C "cmd to execute"
Both work fine for build in cmds, bash-scripts, all nice.
But starting ./Hello or cobcrun ./Hello fails with
libcob: libcob.so.4: cannot open shared object file : no such file or directory
I compared what set gives and the only difference seems to be that set in bash direct gives a env-var LS_COLORS while starting from within windows it does not have the env-var LS_COLORS
where is libcob.so.4 supposed to be and what can i do to convince cobcrun to find it when called from windows via bash -C "cobcrun ./Hello" ?
Mike
Last edit: Michael Sommer 2018-06-19
Just to verify: If you directly start the Devian environment,
cd /mnt/c/projekte/GnuCoboland docobcrun Hellothis works?Additional question: How does your compile command in NPP looks like (you compile from NPP, don't you? If not: please note the exact steps you take for compiling)
OK, simple.
If I start a bash-shell in WSL Debian every thing works fine. cobc compiles with -m or-e, cobcrun runs a module, compiled with -e i can run it direct.
All fine.
But if I start from the windows environment bash with parameters I have a woe.
I can run bash -C "cobc -i" without problems
I can run bash -C 'ls" without problems, but
I can NOT run bash -C "/mnt/c/projekte/GnuCobol/Hello"
then I get the error about missing libcob...
so I made a small bash script
[cross]!/bin/bash
echo Hi Mike
cobcrun ./Hello
read -n 1 -s
and put that into /mnt/c/projekte/GnuCobol where I sucsessfull compiled Hello.cob resulting in Hello and Hello.so
inside bash I can call /mnt/c/projekte/GnuCobol/Test.sh it and it works. called from windows cmd or Desktop Shortcut as
bash -C "/mnt/c/projekte/GnuCobol/Test.sh"
it throws the error about not finding libcob...
WSL documentation states thas instead of calling bash -C ... I also can call wsl.exe ..., but the result is the same, ./Hello does not find libcob and cobcrun does find ./Hello but then also fails with not finding libcob.
if I put a ls in the bash script it confirmes that I am actual in the right directory. and lists Test.sh, Hello, Hello.so and Hello.cob
called from bash shell or from windows cmd/shortcut it does work and list the files, so I am at the right place..
What not work is finding libcob if called from windows cmd or shortcut using bash -C ... or wsl.exe ...
Instead of a ls I put a set there and compared the result, as stated in the first post besides missing LS_COLORS=... both results are the same.
I am pretty sure this is a simple linux issue, but I do not understand linux enough to do further trouble shooting.
So where is libcob supposed to be and what could I do to my bash script to explain to cobcrun where the library has to be searched for?
My Goal is pretty simple, I want a short-cut on the desktop to open a bash shell and start my cobol program.
I have no clue what you are saying abaut NPP
Mike
This may have something to do with interjecting vcvars32.bat or whatever environment setting script bash for windows uses.
https://github.com/Microsoft/WSL/issues/2167
And/or https://stackoverflow.com/questions/366928/invoking-cl-exe-msvc-compiler-in-cygwin-shell
You need to get the CMD environment set before the bash -C or add the settings to a script before launching any libcob runtime it seems.
Your shortcut icon could point to a CMD batch file, set some env vars, then invoke bash -C.
I have no clue what these settings are, but there will be hints somewhere in the WSL system.
If this were me, and I'd be doing this over and over again, I'd probably permanently set the PATH in the Windows GUI and the User Enviroment settings dialog. Or LD_LIBRARY_PATH if that is a thing in WSL space. And then forget the setting and scratch head on an unrelated problem 13 months later... :-)
If WSL supports LD_RUN_PATH, then you may be able to set all the appropriate look up directories before doing a cobc compile, and the rpath should be part of the executable.
I have docs in the FAQ about using LD_RUN_PATH on shared hosting web space systems for COBOL CGI as libcob is not normally part of hosted shells and users don't usually get root powers to be mucking around with the system directories.
Cheers,
Blue
Guys, Guys, Guys.
As allways do not assume anything. THE PROBLEM IS SOLVED.
After Step 1 and 2 I assumed that my old borked UBUNTU was gone. it was not, still there in parallel with my new Debian/testing I installed because Simon told me to do, to use Ludwigs packages.
.And guess what, the bash prompt I got when opening Bash from the Start Menu opened Bash in Debian, since new installed. And there I have GnuCOBOL 2.2.
But the Bash opened by cmd.exe and Short-Links still opened Bash on UBUNTU, my borked Version with OpenCOBOL 1.1.
Both on the same Linux/Windows File System.
So If I start my short-cuts or cmd commands with 'debian -C ...' it uses my Debian Installation and EVERYTHING WORKS.
This is so cool. With this possible we get around all the BDB/VISAM woes on windows and have a easy, and I am a Windows user - very easy way to get GnuCOBOL installed on Win 10.
The 12 step program, sounds familiar, some how, I still need to kick 03 out and add another .12.
No problem with distribution. Customer does the 12 steps, then copy my program on his windows drive sets some short-cuts and DONE. No problem with Oracle...
Super happy,
Mike
Last edit: Michael Sommer 2018-06-21
Update: try this hint
https://github.com/Microsoft/WSL/issues/1363
Look for the comment from jstarks near the bottom of that ticket.
Set WSLENV to a list of environment variables that are passed through. From other reading (no testing) PATH is one of the vars. Looks like it needs a WSL build after Dec 19, 2017.
Aside:
Web servers have the same kinda issue, the CGI environment is somewhat limited (on purpose) and these kinda hints may come in handy for more than just shortcuts.
Cheers,
Blue
Or, fix your installation :-)
Got your last note after posting, Mike, nice.
Have good, make shortcuts,
Blue
Next step is to mount a Windows Network Share to the windows aware file system at mnt/x/, I already found this while googling, have to find it again.
Then compile on one machine and run cobcrun from different W10 Work stations on the same Network drive. Seems doable.
I have a plan for the weekend...
Mike
This may provide some fun and gets you a little bit more comfortable with a real OS ;-)
In general I have no clue why you do all this with WSL...
Just copy the ready-to-use mingw packages (some MB) from Arnold Trembley to each system (or directly to the network share...) and simply use this from Windows instead of installing GNU/kWindows and a complete OS and doing an OS upgrade (multiple GB) on each system...
well, I since years I am fighting with GnuCOBOL on windows. Sure the OCIDE worked well but I could not upgrade it to newer version.
all my tries with mingw and that other one ended in desaster. To complicated for me as non linux user. To easy to bork up when changing little stuff.
I am living from being a programmer and ALL of my customers need Windows Software., relay on Windows Software, use Active Directory and Policies and the Administrators are often not allowed to install Linux insted of windows, for Management reasons.
Not even as Web-Server, sad, sad, situation.
But in over 30 years of programming for my income I never had one company embracing Linux in any form. Maybe the fire-wall can run on linux, else ALL use Windows right now, on Servers and on Desktops. All of them.
But installing a Microsoft Component, named Windows Subsytem for Linux is not at all a problem with these customers and their Management, ist from Microsoft? "Yes" Ok then you can do it.
I know it is sad, but it is what it is.
The next thing is integration to the AD based Management. Once you set up the system policies in the AD right, you simply plug in a new computer and depending on the user logging in the first time, all his needed software gets installed. I have not tested this with wsl but it probabbly works like with any other Software I need to distribute to my new client-workstation, hecck it comes from the Windows Store...
Second is that it is quite invisible and sort of hidden from the end user. Not much there to fiddle with, exept some short-cuts on a network drive and a folder for the COBOL Programs. Very convient for me and my Admins.
Mike
Haha, next step solved. Running from Network Share works
wsl automounts local drives, but no network drives.
but you can map Network drives to the drvfs shared between ww10 and linux at /mnt/xxx
So I can do:
sudo mkdir /mnt/Share .............. one time, it is persistent
sudo mount -t drvfs '\Pavillion22\Share' /mnt/Share .......... every time, not persitent.
and have my windows network drive available for the Linux Subsystem.
To make this persistend I need to modyfy /etc/bashrc.bash and add the following line at the beginning:
echo mysudopassword | sudo -S mount -t drvfs '\Pavillion22\Share' /mnt/Share
and voila ech new opened Bsh window and each Batch or Short-cut started program knows /mnt/Share. Without asking for a sudo Password.
And the credential used for accessing the network drive are the credentials from the current windows user as it should be.
This is complete seamless integration, easy to handle for Windows Admins, almost invisible to the client.
this is so nice. And ALL the goodies will work for windows user, like Brians scripting efforts, no worries on how to install RED on Windows, no need for special windows treatment,...
Mike
Last edit: Michael Sommer 2018-06-21
I even got rid of manipulating /etc/bash.bashrc. for accessing network shares., more grunt work on the windows side,
A shortcut looks like this now:
debian.exe -C "echo mysudopassword | sudo -S mount -t drvfs '\Inspirion\WorkHorse' /mnt/WorkHorse && clear && echo -ne '\e]0;Hello in GnuCOBOL\a' && /mnt/WorkHorse/bin/Hello"
But just need a running debian with GnuCOBOL, just the 12 steps, nothing more.
Might work with other distros too.
this is wonderful,
Mike
Last edit: Michael Sommer 2018-06-22
This thread may morph into a FAQ entry, if you don't mind, Mike.
Have good, make well,
Blue
I still need Ludwig to get a package out for the latest GnuCOBOL 3.x so I can uprgrade to that on Debian/Testing .
But right now I test install options, the 12 steps might be able to be reduced to 5-6 or so,
and I do not mind at all
Mike
You get the install steps down and get most current if you don't upgrade the underlying Debian repo (which was needed to use the currently "testing" packages) but build from source.
For this: Do only the first update + upgrade parts (may be specified on a single line, combined with
&&if you like to), then install the prerequistes listed in the README file viaapt-get install XYZ(you may check manually on a clean installation which minimal packages you need), additional installwget, thenwgetthe source tarball and do thetar -xf gnucobol-XYZ.tar.xz && cd gnucobol* && configure && make && make installsteps. This has also the benefit that you download much less.My idea of using a predefined package is to avoid all of this.
As stated before this is for Windows User not at all versed in Windows itself, and for sure NOT able to install GnuCOBOL from source on Linux.
That was something even I was not able to archive yet, I know the common knowledge here is that any programmer is supposed to use linux or he is a moron, but hell then I am a moron.
But what is worse is, that the customers I have and are in need of some software I really would like to use COBOL for instead of Windows VS-Studio Applicatinos have already trouble to install Windows Programs or even Features. They are no programmer at all, they are construction worker, foremen, Plumber, Roofer, barey handling the website to put in bids for upcoming projects.
Building GnuCOL from source is simply to much to ask for. Even the current 12 step program is.
Mike
There are many people using GnuCOBOL that have no clue about non windows systems. (this is also shown by the downloads stars, which primarily track only windows users), don't feel bad about it.
I still would recommend anyone (including the person groups you've bored) to have a look at a free, secure and not tracking OS, not for GnuCOBOL or GNU but for their own best - but this still won't mean they must be able to do a source build - that is what distributions are for and debian does a very good job here. Thanks to Ludwin also for GnuCOBOL now.
Note: the target for WSL is officially still "a programmer that is familiar with Linux and want to use tools he knows on Windows".
People that feel themselve forced to use Windows (or force themselve to do this) need a much easier option than building a software from source and Arnolds builds provides it.
Unpack a community trusted archive and use it as a portable software, zero configuration needed.
If needed you can create your own package for tweaks or full control of the version of any program it includes. A security audit can even inspect all sources until it reaches the Windows internal dlls (try this with a MicroFocus/Fujitsu/whatever COBOL compiler / runtime).
I don't see why this should be bad in a corporate environment...
Aww, that's not usually what the digs about Windows are supposed to imply, Mike. No morons. Few morons even know what GnuCOBOL is, let alone COBOL.
This isn't really supposed to come off as bad side good side.
This is ok side better side. :-)
Now, risks are up a bit. WSL is somewhat dangerous ground for long term free software growth. Part of picking up GNU/Linux is ensuring freedom, now and into how ever long it lasts, not simply smarts or level of computing aptitude. Consumers are at a disadvantage with the freedom of choice to step up to POSIX for work at this point, developers should exercise the freedoms. And then spread them.
That's the message in the medium, Mike, at least when I'm taking pokes. Paint grenades over the wall. But for a good cause.
Cheers,
Blue
And just a precautionary, Mike.
I'm pretty sure package builds are Berkeley DB, unless advertised otherwise.
If you distrubute libcob software outside company walls then a clause in bdb licensing states need for a deal with Oracle or provide source with your binaries.
As with most things in these licensing issues, distribution of code is usually the trigger. Personal use (including a companies' personal) is personal use. Which is one of, if not thee point of free software; end user rights to modify to suit purpose. Those freedoms include no obligation to share; only obligations to not impede further freedoms, once shared.
And that was just preachy, sorry.
Anyway, just so everyone knows the implications of the official repo builds at this point, from what I've looked at so far for packaging dependencies. There are alternatives, for rebuilds.
Have good, make stuff,
Blue
Please be more clear here. Installing a debian package fior libcob (not distributing it with the COBOL modules) at a customer side is just installing the package. As long as you ship the generated COBOL modules for use with a package I see no license issues, do you?
Additional note: as long as configure.ac is not fixed you may trap on the issue tracked with [feature-requests:#318].
I wish I could be more clear, Simon...my non-lawyer brain never quite gets it.
So, http://www.oracle.com/technetwork/database/berkeleydb/downloads/licensing-098979.html
"Our open source license is OSI-certified and permits use of Berkeley DB in open source projects or in applications that are not distributed to third parties. Our commercial license permits closed-source distribution of an application to third parties and provides business assurance."
...
"The following are not redistribution:
"
But, I'm more than willing to be corrected on what that means at face value.
And again, there are alternatives; a show bump, not a show stop.
And, free software is always the best model anyway, so... :-)
Cheers,
Blue
This is an explanation. If you check the actual license this is about it is the GNU AFFERO GENERAL PUBLIC LICENSE.
Note: this only applies to more recent versions of Berkeley DB, older versions have the Sleepycat license which has different license results.
Doh
Hi Mike
I just wanted to thank you for this thread. I hate WIndows but I am in the same situation, all of my customers run Windows. I have never seen Linux used in a laboratory, not once.
I just setup Windows 10 and I have Debain under WLS up and running now.
Hi Brian
I know what you are saying about WLS eating away at GNU but this is a path forward for me and I can encourage people to switch over to Linux if they have a cool Linux app running under Windows. This might be a good tool for evangelicals to get people to switch.
-Pat
Well, my thinking was along Simons, that when my customer installs LSW+ GnuCOBOL with BDB and I just provide my Software, I do NOT violate BDBs licencing.
If I do, then the whole thing is dead in the water.
I do understand that Brian is a evangelist, preaching freedom for software, Linux for user, etc, etc.
But this is actual the main problem I have with this. preaching freedom, but not allowing me to NOT opening my source. What freedom is this? The freedom to do as Stallman wants?
This is even worse then MS. OK I need to buy VS, but I am FREE in my decision if I provide my source or not and I can install whatever I produce on any Windows machine and - up to some point - even on Linux using Mono or Wine. Without any restrictions.
And without any licensing fees per installation.
Programming is my Job, my only means of income since 30+ years. I need to sell my software and I am neither willing not able to give it away for nothing.
As far as I can follow GnuCOBOL, ISAM/VSAM is not working correctly and no one is working on it, so to use indexed files I need to use BDB. Maybe I am wrong here but the only alternative I can see is to use ODBC, EXEC SQL and a preprocessor, destroing all the beauty of COBOLs internal filehandling.
Sad, sad, sad,
Mike