Date: prev next · Thread: first prev next last
2014 Archives by date, by thread · List index


Hi :)
So on the command-line you would do something like

cd c:/Documents and Settings/Joe B/My Documents/html files

to get into the right folder and then run the batch file from there.  I'm
not sure if you can use

cd c:

tbh, i think you have to skip the c: bit and plunge straight into the rest
of it.  Also there is likely to be problems with the spaces so you might
have to use "escape characters" making it more like

cd "Documents and Settings"/"Joe B"/blah..

or

cd Documents\ and\ Settings/Joe\ B/My\ Documents/html\ files

or some other strangeness.  It's why i prefer to avoid using spaces in file
and folder names.  CamelCase is so much easier.
Regards from
Tom :)





On 11 April 2014 09:24, Tom Davies <tomcecf@gmail.com> wrote:

Hi :)
I've just got up and not even had my first cuppa tea yet!  Paul has been
amazing!  Good work there!  I used to enjoy creating simple batch files but
Paul really takes it several plateau's higher.

I think the batch file just acts on whichever folder you happen to run it
from.  You can "cd" into a new directory on the command-line and then
re-run the batch file.  There are codes you can use to look for input from
the command-line and then use that as the pathname but by default it'll
just act in the folder you are currently in.  It might be worth adding that
question to the Ask LO thread.

The tricky bit is knowing where to put the batch file so that Windows can
run it from anywhere.  Maybe the root directory, C: ?  It's not very
elegant and is probably bad practice security-wise but i don't know a
better answer.

Regards from
Tom :)



On 11 April 2014 04:18, Joe B <paperbag76@gmail.com> wrote:

Paul, your answers are extremely helpful and polite.
I know you won't see this for awhile.  That's ok.  I can't believe you're
still up anyways, seeing as I think you're in South Africa from your
e-mail
address.

I think I've sort of underestimated my explanation of my knowledge of
computer science to you.  I do understand for-loops very well.  What I am
asking has more to do with paths and filesystems I think.
When I say, "Where does the .bat file for-loop know where to find the .htm
files to iterate over?", I don't mean in the actual for-loop code.  I
understand, the for loop code looks at the "conditional" part of the
for-loop.  What I mean is, where is this list of files in the computer's
filesystem?

I think this quote of yours might get to the heart of the issue:

"but that would mean typing out all the filenames. By using a wildcard
character (see: http://www.ahuka.com/?page_id=31) DOS knows that this
means the list consists of all the files in the current directory that
have the ".htm" extension."

When you say "the list consists of all the files in the *current
*directory
that have the .htm extension", that's what I'm getting at, when I say,
"where does the .bat file know where to get its input .htm files from?".
The filesystem directory.

In sum: Does this mean that my .bat file would have to go into the same
windows directory as my input .htm files, in order to know which ".htm"
files it should use to create the glob?

And thus, generally speaking, does this mean that .bat files must always
go
into the same directory as the files that they take as input?

I'm really sorry if this is basic stupid questions.  I learned some high
level languages, but never DOS.

thank you,
joe





On Thu, Apr 10, 2014 at 9:26 PM, Paul <paulsteyn1@afrihost.co.za> wrote:

Hi Joe,


On Thu, 10 Apr 2014 20:21:06 -0500
Joe B <paperbag76@gmail.com> wrote:

set path=%path%;C:\Program Files (x86)\LibreOffice 4\programfor %f in
(*.odg) do (
    soffice.exe --headless --convert-to pdf --outdir "C:\tmp" %f)
Let me format that a bit better, tweak it slightly, and change it to
match your requirements (although you must still change "C:\tmp" to
your preferred location):

1) set path=%path%;C:\Program Files (x86)\LibreOffice 4\program
2) for %f in (*.htm) do soffice.exe --headless --convert-to pdf --outdir
"C:\tmp" %f

Sorry if this wordwraps. It's meant to be only two lines, and I have
numbered each line, which is not supposed to be part of the line.

I do not know what language this is.
This is what used to be DOS, and is now cmd.com under Windows, which
provides a command line with the same syntax as DOS. On *nix systems
this is called a shell script, in the windows world it's a batch file,
and sometimes also referred to as shell scripting. See here for an
intro:

http://www.computerhope.com/batch.htm

This is therefore not a language per se, but rather commands that the
command line interpreter understands.

So this could either be typed into the command line one line at a time,
pressing enter after each line, or this could all be put in a file,
called a batch file and given the ".bat" extension, and run as one
single item. Either way is almost exactly the same. A batch file is
simply a plain text file of DOS commands (I'm going to call them that
for simplicities sake) that cmd.com knows to execute by running each
line as if it were typed into the terminal directly. The only
difference in this instance is that if the commands are run line by line
from the command line, using "%f" as above is fine, but if they are in
a batch file instead, you need "%%f", so the second line becomes:

2) for %%f in (*.htm) do soffice.exe --headless --convert-to pdf
--outdir "C:\tmp" %%f

Here is my understanding of the code.  The writer first adds the
LibreOffice directory to the "path" environment variable.  Path is a
Windows operating system environment variable containing special
directories.  These directories tell Windows where to look for
executable files. Thus, any executable file that is in a folder, that
is in the "path" environment variable, can be run at the command
prompt by simply typing its name, without having to specify exactly
where it is.  For example, typing "soffice" (just the executable
file's name) at the command prompt, instead of "C:\Program Files
(x86)\LibreOffice 4\program", will open soffice.exe. It makes using
the command line simpler and quicker. In that way, the writer can
simply start his code in the for loop with "soffice".
Exactly correct.

What I don't understand is, how does the batch file know where to
look for the input files?  All that the batch file is given is an
iterator variable %f.
The batch file would be the whole thing, so the "batch file" as you put
it isn't given anything, it's just run. Line two can be broken up into
the following fragments:

1) for %f in (*.htm) do
2) soffice.exe --headless --convert-to pdf --outdir "C:\tmp" %f

The first fragment is a "for" command, which is a built in DOS command,
i.e. cmd.com knows what to do with it without needing to run a program.
Almost anything you type at the command line is either a builtin
command or the name of a program to run. See here for more info on the
"for" command:
http://www.robvanderwoude.com/for.php

The for command iterates over a list and executes a command for each
item in the list.

The for command consists of the keyword "for", a variable to hold each
iteration of the list, the "in" keyword, a list to iterate over in
brackets, and the "do" keyword, and then a command to execute for each
item in the list (the second fragment). Here the variable is "f", and to
tell DOS that it is a variable, we need to precede it with a percent
sign, or two if it is in a batch file.

The for loop will execute the second fragment for each item in the
list, and each time the "%f" will hold the next item in the list. In
this case the items in the list are all the files with a ".htm"
extension, so each time the second fragment is run, the "%f" will hold
the name of the next file with an ".htm" extension.

The list can be given as, say, a simple list, like so

"(file1.htm file2.htm file3.htm)"

but that would mean typing out all the filenames. By using a wildcard
character (see: http://www.ahuka.com/?page_id=31) DOS knows that this
means the list consists of all the files in the current directory that
have the ".htm" extension.

The second fragment, therefore, is run multiple times, each time with a
different filename, and does exactly what you would expect.

This iterator variable ideally takes on the
values, one by one, of the file names that end with .odg (in this
case).  But how does the command line know where to look to find
those .odg files to convert in the first place?
From the above I hope it is clear that it comes from the for loop,
specifically from the "(*.htm)"

Remember, the "dir" command is another builtin, and it takes a
list of files and displays each one with its size and other attributes.
So you can either give "dir" a single file to list (or multiple files
separated by space), or give it a filename with wildcards to match more
than one file. DOS actually replaces the filename pattern that contains
the wildcards with a list of files that match and hands that list to
"dir". In the same way the "for" command takes a list of files, and DOS
simply translates that wildcard pattern into a list of files for us
before handing it to the "for" command.

It's called shell globbing, and basically it means that the shell
(cmd.com in this case) will translate a filename with wildcards into a
list of filenames that match, before actually calling the builtin or
program. It doesn't work everywhere, in some places the shell doesn't
glob, and in others even though it does, the program or builtin
doesn't accept more than one single file and so won't work despite
the shell actually doing the globbing, but most places you need to give
a filename you can use wildcards and the shell will glob it, and any
program or builtin that works with a list of files will be happy.

http://en.wikipedia.org/wiki/Glob_%28programming%29

Thanks again, and sorry for so many questions.  I just feel so close,
and I've been working on this problem for days.
No worries. Hope this makes it all clear to you.

I'm heading for bed now, so if there is anything else, please feel free
to ask, but expect a little longer delay in my response this time :)

Paul

--
To unsubscribe e-mail to: users+unsubscribe@global.libreoffice.org
Problems?
http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more:
http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/users/
All messages sent to this list will be publicly archived and cannot be
deleted



--
To unsubscribe e-mail to: users+unsubscribe@global.libreoffice.org
Problems?
http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/users/
All messages sent to this list will be publicly archived and cannot be
deleted




-- 
To unsubscribe e-mail to: users+unsubscribe@global.libreoffice.org
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/users/
All messages sent to this list will be publicly archived and cannot be deleted

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.