Batch File Problem

[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?

 

[Pegasus [MVP]]

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?

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.

 

[Sid Elbow]

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.

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).

 

[me]

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).

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

 

[Pegasus [MVP]]

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).

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

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

 

[Sid Elbow]

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

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

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 Elbow]

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

..... 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!

 

[Pegasus [MVP]]

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.

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%

 

[Sid Elbow]

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

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.

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.

 

[Sid Elbow]

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%

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.

 

[Pegasus [MVP]]

.... 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!

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 . . .).

 

[me]

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 . . .).

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

 

[Sid Elbow]

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 . .
.).

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.

 

[Sid Elbow]

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.

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).

 

[Pegasus [MVP]]

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.

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

 

[Sid Elbow]

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

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".

 

[Pegasus [MVP]]

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".

Great - and what is the working directory that gets reported by the code I
suggeste?
echo The current working directory is %cd%
pause

 

[Sid Elbow]

Great - and what is the working directory that gets reported by the code
I suggeste?
echo The current working directory is %cd%
pause

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

.... exactly as reported in my response to me@tadyatam yesterday.

 

[me]

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).

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

 

[Sid Elbow]

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:"

Thanks .... I appreciate the help.