A question for IT professionals who work daily in both the Linux and Windows worlds.

I created a shell script that converts to raw text files certain PDF files containing columns, where the text in the columns is more easily manipulated. Those text files are imported to a proprietary Windows app. The shell script works wonderfully.

For me.

Unfortunately, I no longer am the only person who needs these conversions. Now a handful of non computer Windows people need the same conversions.

The challenge: convert the shell script into a tool that will be used by non computer people in Windows. Basically that means a point-and-click interface.

Non computer people.

Using a terminal and typing commands is out of the question. A work-around to that criterion is if the script runs transparently as a desktop shortcut. I have created several small "batch files" for these people that run this way. Users point and click to the script shortcut but never actually deal with a terminal window. A similar solution could succeed here too.

I am not seeking a shell script conversion tool. The shell script will need to be ported manually line-by-line.

My shell script depends upon the following tools and commands:

pdftk (cross platform availability)
pdftotext (xpdf/poppler: cross platform availability)
Linux shell built-in commands: exit, for/done, if/then
Linux coreutils: echo, ls, grep, cut, sort, head, tail, rm, cat
Linux gawk
Linux sed

I am aware of and have used the GNUWin32 tools. However, a single self-contained app would be received much better by IT personnel than having to install multiple tools and packages. If using a scripting language then possibly I can create the illusion of a single app by storing all commands in the same directory and calling that a "package."

I am not versed in python or perl, but am ready to learn some basics if those scripting languages are viable options. I can't code in C or C++, but hiring a coder is an option.

I am familiar with Visual Basic for Apps (VBA), therefore VB Script (VBS) might be an option too, although I never have touched VB Script.

I have written "batch files," but would prefer to avoid such a limited and obtuse environment.

I am unfamiliar with Windows power shell, but will look into that if suggested.

For the curious: I use Windows in a virtual machine in a Slackware host. Writing the shell script was natural for me. I expected that one day I would need to convert the shell script and that day now has come to haunt me.

Thanks much!

I think that a script that manipulates text is much easier ported to Python or Perl than to a Windows batch file.
Positive side-effect: If you learn one of the languages (or both ) you can easily write your scripts in that language for platform independence in future.

How about using the VM guest and a share? If the conversion doesn't take ages how about letting them drag 'n drop their file and pick it up when processed? That could, apart from them using their mouse, 0) completely hide internals too and 1) avoids you having to convert anything and 2) centralize maintenance and development (if any)...

I'll avoid batch files as much as possible. Python and Perl are portable, but I don't yet know if these languages are supported by IT (still waiting for an answer). If I understand correctly Perl has built-in routines for many shell commands.

If I understand correctly there are GUI wrappers for both languages.

I would not mind improving my skills by learning either language, but I don't have that luxury at the moment. The other users want something now.

Currently I am leaning toward VB Script. Not as flashy as Python or Perl, but as that language is native to Windows, that might be the most straightforward solution. I'm still open to Python or Perl as long as I can get the script to run as a desktop shortcut. But to do that I'll have to "idiot-proof" the script far more than I currently have with my shell script. Nothing new there --- that is normal for any script or program that gets used by anybody other than the original developer.

I too thought about that idea, but I don't know what virtual machine options IT supports. I have been performing these conversions on my personal office machine. I can do anything I want on my machine. All of that freedom disappears on any IT controlled system. Yet I am afraid that running a VM is a tad too much for non computer people. I have to deal with the reality of this lowest common denominator. To implement such an idea I would need to install a Linux based system in whatever VM environment IT might support. I can envision that succeeding for you and me, but not these people.

Bummer. I was hoping your VM guest would be inside their network and they would allow you to host the "service" for the network. Would have been a win-win situation: no extra work and liabilities for them and no additional work for you. I probably should have asked more questions first...

Indeed.

I'm wondering whether Cygwin might succeed. I'm not sure I can create a simple desktop shortcut to run the shell script in that environment. Another challenge is each user needs the Cygwin environment installed or have access to that environment somewhere on the network.

The original shell script executes fast, but the terminal window must execute transparently to the users. Let them double-click on the shortcut. When they open the File Explorer they find the converted text files in an expected or known folder. All of this is magic to them --- black magic.

Edit: A little searching reveals that running my shell script from a Windows desktop shortcut through Cygwin is straightforward:

start c:\cygwin\bin\bash.exe /full/path/to/myscript

All I need then is to get IT support to install Cygwin to a common network location so all users have access. As the script runs fast a network install of Cygwin should not pose serious issues. Sure would be nice if the final solution ends up being this easy. Sounds like I have some testing to perform in my Windows virtual machine.

Another alternative would be to make a directory on your Slackware box available to all users. You could use inotify to watch for a file being created in that directory and use that signal to run your script. Your Windows users would only need to copy their file to that directory to trigger the script.
You would need the script output to go to another directory or perhaps add a test for .pdf files to inotifywait.

That's a slick idea.

Unfortunately my office machine is not part of the other users' network. I'm developing these tools off site.

The good news is I have had good success today testing Cygwin in my Windows virtual machine to simulate the network. One nice thing is I need not worry about porting my script to another language. I'm using the normal Cygwin desktop shortcut and some $HOME/.bashrc tweaks to automate the process. A few minor script tweaks to accomodate differences between a Slackware system and Cygwin.

Do they really need to run the reports themselves? I dont know the applicability for you situation or environment but I do a similar task but I run it from a server and email the files daily via a cron job. Everyone gets the reports they want and I only hear about it when they dont get those reports.

Yes, although these files are not reports. They are PDF conversions to text. The PDFs contain columns, which are a bugger to copy and paste from because of the way PDFs are formatted. The best solution was to convert to text to import into the new app.

There are several hundred of these documents. They get converted and imported on an as-needed basis. A one-time batch conversion won't work because the older documents are still maintained in some old proprietary software and in emergencies the employees use the old software to update the documents. The conversion to the new app is a long-term project. I could perform a batch conversion of all the files but those intermediary files are not "official" and can be easily outdated by any emergency updating with the old proprietary software. So no sense in converting until everybody is ready for each document.

A fascinating part of this project is how easily I wrote a shell script to perform the conversions, along with running Windows in a virtual machine. I likely could have conjured up a VB Script to perform the same conversion process in Windows by using the GNUWin32 tool set. My script depends upon classic cornerstones like grep, sed, and awk in addition to pdftk and pdftotext. All of that could have been done in Windows but none of the tool set is native. I'm not bashing Windows, just observing how much we 'nixers take for granted with respect to built-in environments and tool sets.