Batch File Problem

  • Thread starter Thread starter Sid Elbow
  • Start date Start date
S

Sid Elbow

I'm trying to run the following batch file:


@echo off

rem ***Set cbreak parms here, after the equals sign ***
set cbreakparms=-b60 -d20 -s60

:again
if "%1"=="" goto end
mkdir "%~dp1cbreak"
cbreak "%1" "%~dp1cbreak\%~nx1" %cbreakparms%
shift
goto again
:end

It fails with the message:

" 'cbreak' is not recognized as an internal or external command,
operable program or batch file"

..... yet the program cbreak.exe does exist and is in the same directory
as the batch file. If I edit the batch file and give the full path to
cbreak the batch will run correctly - I don't particularly want to do
that since it will make the batch file location-dependent.

Why does it not find cbreak in it's own directory?
 
Sid Elbow said:
I'm trying to run the following batch file:


@echo off

rem ***Set cbreak parms here, after the equals sign ***
set cbreakparms=-b60 -d20 -s60

:again
if "%1"=="" goto end
mkdir "%~dp1cbreak"
cbreak "%1" "%~dp1cbreak\%~nx1" %cbreakparms%
shift
goto again
:end

It fails with the message:

" 'cbreak' is not recognized as an internal or external command, operable
program or batch file"

.... yet the program cbreak.exe does exist and is in the same directory as
the batch file. If I edit the batch file and give the full path to cbreak
the batch will run correctly - I don't particularly want to do that since
it will make the batch file location-dependent.

Why does it not find cbreak in it's own directory?
Click to expand...

I suspect that the above is not the batch file that generates the error
message. I also can't quite see how the line
cbreak "%1" "%~dp1cbreak\%~nx1" %cbreakparms%
could work. AFAIR, the code you use requires a "for %%a in" construct.

I would set "echo on" to see which line generates the error.
 
Pegasus said:
I suspect that the above is not the batch file that generates the error
message. I also can't quite see how the line
cbreak "%1" "%~dp1cbreak\%~nx1" %cbreakparms%
could work. AFAIR, the code you use requires a "for %%a in" construct.

I would set "echo on" to see which line generates the error.
Click to expand...


Thanks for the response, Pegasus.

I did as you suggested and turned echo on. It is indeed the line:

cbreak "%1" "%~dp1cbreak\%~nx1" %cbreakparms%

which generates the error.


Some background .... the program cbreak.exe is used (with some
command-line parameters) to remove commercials from video files. The
above batch file is used by drag-and-drop'ing a number of video files on
to the batch file. In my (somewhat limited) understanding, this sets the
batch file parameters (%1, %2, %3 etc) to the names of those files. The
"shift" command is then used to present each file in turn to the
cbreak.exe program along with an output directory and some control
parameters.

In fact, that part of the batch file seems to work if I put in the full
path for cbreak.exe, but I don't understand why that is necessary (since
all involved files are in the same directory).
 
Thanks for the response, Pegasus.

I did as you suggested and turned echo on. It is indeed the
line:

cbreak "%1" "%~dp1cbreak\%~nx1" %cbreakparms%

which generates the error.


Some background .... the program cbreak.exe is used (with
some command-line parameters) to remove commercials from
video files. The above batch file is used by
drag-and-drop'ing a number of video files on to the batch
file. In my (somewhat limited) understanding, this sets the
batch file parameters (%1, %2, %3 etc) to the names of
those files. The "shift" command is then used to present
each file in turn to the cbreak.exe program along with an
output directory and some control parameters.

In fact, that part of the batch file seems to work if I put
in the full path for cbreak.exe, but I don't understand why
that is necessary (since all involved files are in the same
directory).
Click to expand...

Sid,

Suggestion: add justt before "cbreak" a la
cd
pause

You need full path to the .exe because the path is relative to
current dir, not to whatever is passed to the .bat

I think (it's been a while) that a .bat may run with Documents
and Settings as its current dir when you invoke it via
drag&drop or Sent To. I have notes about that somewhere ... if
you wish, I'll try harder to remember where.

J
 
Sid Elbow said:
Thanks for the response, Pegasus.

I did as you suggested and turned echo on. It is indeed the line:

cbreak "%1" "%~dp1cbreak\%~nx1" %cbreakparms%

which generates the error.


Some background .... the program cbreak.exe is used (with some
command-line parameters) to remove commercials from video files. The above
batch file is used by drag-and-drop'ing a number of video files on to the
batch file. In my (somewhat limited) understanding, this sets the batch
file parameters (%1, %2, %3 etc) to the names of those files. The "shift"
command is then used to present each file in turn to the cbreak.exe
program along with an output directory and some control parameters.

In fact, that part of the batch file seems to work if I put in the full
path for cbreak.exe, but I don't understand why that is necessary (since
all involved files are in the same directory).
Click to expand...

OK, what happens when you invoke cbreak in its fully qualified form?

"c:\Some Folder\cbreak.exe" "%1" "%~dp1cbreak\%~nx1" %cbreakparms%
 
Pegasus said:
OK, what happens when you invoke cbreak in its fully qualified form?

"c:\Some Folder\cbreak.exe" "%1" "%~dp1cbreak\%~nx1" %cbreakparms%
Click to expand...

Well, yes - that's what I meant by "....that part of the batch file
seems to work if I put in the full path for cbreak.exe". It works fine
under those circumstances - but then the batch file becomes specific to
that location: if I move the files to another directory I have to edit
the batch.

Incidentally, I did try putting a copy of cbreak.exe on the command path
(....\system32) but that didn't help.
 
Sid said:
Incidentally, I did try putting a copy of cbreak.exe on the command path
(....\system32) but that didn't help.
Click to expand...

..... sorry - this did work after all. I have a multi-boot system (3xOS)
using the Windows boot manager and was using the wrong ....\Sytem32
directory when I wrote that. Duh!
 
Sid Elbow said:
Well, yes - that's what I meant by "....that part of the batch file seems
to work if I put in the full path for cbreak.exe". It works fine under
those circumstances - but then the batch file becomes specific to that
location: if I move the files to another directory I have to edit the
batch.

Incidentally, I did try putting a copy of cbreak.exe on the command path
(....\system32) but that didn't help.
Click to expand...

If the program works fine with a fully qualified path but fails when just
specifying "cbreak" then you're running something other than what you think
you run. In other words, there is a cbreak.com, .vbs, .bat or .cmd lurking
around that you have not considered so far. You can easily prove it like so:
- Rename cbreak.exe to MyCbreak.exe
- Modify the line
cbreak "%1" "%~dp1cbreak\%~nx1" %cbreakparms%
to
MyCbreak "%1" "%~dp1cbreak\%~nx1" %cbreakparms%
 
Suggestion: add justt before "cbreak" a la
cd
pause
Click to expand...

Tried that - it didn't help


You need full path to the .exe because the path is relative to
current dir, not to whatever is passed to the .bat

I think (it's been a while) that a .bat may run with Documents
and Settings as its current dir when you invoke it via
drag&drop or Sent To. I have notes about that somewhere ... if
you wish, I'll try harder to remember where.
Click to expand...

I think you hit the nail on the head with this. When I tried your first
suggestion, I notice that command prompt during batch file operation
shows the current directory as ...\documents and Settings\<user>. So it
seems that if, in the GUI, I open a window to, say, E:/mydir containing
a .bat file, then drag-and-drop some files onto the .bat, windows runs
said batch file from the user-directory. That strikes me as less than
useful.

In any event, it seems I can get around it by putting the cbreak.exe
program on the command-path.
 
If the program works fine with a fully qualified path but fails when
just specifying "cbreak" then you're running something other than what
you think you run. In other words, there is a cbreak.com, .vbs, .bat or
.cmd lurking around that you have not considered so far. You can easily
prove it like so:
- Rename cbreak.exe to MyCbreak.exe
- Modify the line
cbreak "%1" "%~dp1cbreak\%~nx1" %cbreakparms%
to
MyCbreak "%1" "%~dp1cbreak\%~nx1" %cbreakparms%
Click to expand...

As mentioned, error message produced states:

" 'cbreak' is not recognized as an internal or external command,
operable program or batch file"

that seems to mean that it can't find cbreak at all (in any command
form) so I'm not running something other than what I think: I'm not
running anything at all.


Nonetheless, I had previously tried using the full filename (cbreak.exe)
without success which should have eliminated the alternative command
forms but your suggestion was even better .... unfortunately it didn't
make any difference either.

I think the other response to the thread has pinpointed the problem.
Although I assumed that that, when I invoke a .bat from a specific
directory, the command shell would run it in that directory it seems
that's not what it does. It's apparently run in the current
user-directory - at least when you drag-and-drop to the batch file. I
frankly don't see any logic to that so perhaps its a genuine bug.
 
Sid Elbow said:
.... sorry - this did work after all. I have a multi-boot system (3xOS)
using the Windows boot manager and was using the wrong ....\Sytem32
directory when I wrote that. Duh!
Click to expand...

If putting a copy of cbreak.exe into a directory such as system32 fixes the
problem then this means that you're changing your working directory at some
stage in your batch file. Unfortunately the code you posted does not show
that change. In a court of law they might say that you're withholding key
evidence (and leading respondents up the garden path . . .).
 
If putting a copy of cbreak.exe into a directory such as
system32 fixes the problem then this means that you're
changing your working directory at some stage in your batch
file. Unfortunately the code you posted does not show that
change. In a court of law they might say that you're
withholding key evidence (and leading respondents up the
garden path . . .).
Click to expand...

It's the OS. It starts Drag'n'Drops on a .BAT in "Documents
and Settings". If that .BAT tries to invoke an .exe, .bat,
etc. without an explicit path, W2k cannot, of course, run it
unless the .exe, etc. it's on the path.

J
 
Pegasus said:
If putting a copy of cbreak.exe into a directory such as system32 fixes
the problem then this means that you're changing your working directory
at some stage in your batch file. Unfortunately the code you posted does
not show that change. In a court of law they might say that you're
withholding key evidence (and leading respondents up the garden path . .
.).
Click to expand...

:-)

Definitely not trying to lead you up the garden path, Pegasus. The code
I posted (which I didn't write) is *exactly* what I'm running (I cut and
pasted it to be certain). It appears, as noted in other messages in the
thread, that it is Windows itself which is leading us both up the garden
path by running the batch in the user-directory (...\documents and
Settings\<user>) rather than the directory which contains the batch.
 
It's the OS. It starts Drag'n'Drops on a .BAT in "Documents
and Settings". If that .BAT tries to invoke an .exe, .bat,
etc. without an explicit path, W2k cannot, of course, run it
unless the .exe, etc. it's on the path.
Click to expand...

Does this behaviour occur only in the case of drag-and-drops then?

(I still don't see any logical reason for MS doing it that way).
 
Sid Elbow said:
As mentioned, error message produced states:

" 'cbreak' is not recognized as an internal or external command, operable
program or batch file"

that seems to mean that it can't find cbreak at all (in any command form)
so I'm not running something other than what I think: I'm not running
anything at all.


Nonetheless, I had previously tried using the full filename (cbreak.exe)
without success which should have eliminated the alternative command forms
but your suggestion was even better .... unfortunately it didn't make any
difference either.

I think the other response to the thread has pinpointed the problem.
Although I assumed that that, when I invoke a .bat from a specific
directory, the command shell would run it in that directory it seems
that's not what it does. It's apparently run in the current
user-directory - at least when you drag-and-drop to the batch file. I
frankly don't see any logic to that so perhaps its a genuine bug.
Click to expand...

It all depends what you mean with "when I invoke a .bat from a specific
directory", e.g. you invoke it
a) at the Command Prompt while in the specific directory; or
b) at the Command Prompt while in any directory, by fully qualifying the
batch file's name; or
c) via a shortcut by fully qualifying the batch file's name, with or without
specifying the working folder; or
d) by dragging and dropping

Suffice it to say that your tests prove conclusively that you were not in
the appropriate folder when the command failed. Modifying your batch file as
below will prove it beyond doubt:

@echo off
rem ***Set cbreak parms here, after the equals sign ***
set cbreakparms=-b60 -d20 -s60

:again
if "%1"=="" goto end
echo The current working directory is %cd%
pause
mkdir "%~dp1cbreak"
cbreak "%1" "%~dp1cbreak\%~nx1" %cbreakparms%
shift
goto again
:end
 
Pegasus said:
It all depends what you mean with "when I invoke a .bat from a specific
directory", e.g. you invoke it
a) at the Command Prompt while in the specific directory; or
b) at the Command Prompt while in any directory, by fully qualifying the
batch file's name; or
c) via a shortcut by fully qualifying the batch file's name, with or
without specifying the working folder; or
d) by dragging and dropping
Click to expand...




Like it says farther on in the same paragraph "at least when you
drag-and-drop to the batch file". Plus, as I said in my first reply to
you in the thread "The .... batch file is used by drag-and-drop'ing a
number of video files on to the batch file".
 
Sid Elbow said:
Like it says farther on in the same paragraph "at least when you
drag-and-drop to the batch file". Plus, as I said in my first reply to you
in the thread "The .... batch file is used by drag-and-drop'ing a number
of video files on to the batch file".
Click to expand...

Great - and what is the working directory that gets reported by the code I
suggeste?
echo The current working directory is %cd%
pause
 
Pegasus said:
Great - and what is the working directory that gets reported by the code
I suggeste?
echo The current working directory is %cd%
pause
Click to expand...

OK, its \Documents and Settings\<user>.

.... exactly as reported in my response to me@tadyatam yesterday.
 
Does this behaviour occur only in the case of
drag-and-drops then?

(I still don't see any logical reason for MS doing it that
way).
Click to expand...

Drag-and-drops and copy-and-paste on .BATs start in
%USERPROFILE%, e.g. C:\Documents and Settings\xyz

Ditto when a .LNK to .BAT does not spefify "Start in:"

J
 
Drag-and-drops and copy-and-paste on .BATs start in
%USERPROFILE%, e.g. C:\Documents and Settings\xyz

Ditto when a .LNK to .BAT does not spefify "Start in:"
Click to expand...

Thanks .... I appreciate the help.
 
Back
Top