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

"Sid Elbow" wrote in message

news:4b8ee111$0$14756$c3e8da3@news.astraweb.com...

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

Pegasus [MVP] wrote:

>

>

> "Sid Elbow" wrote in message

> news:4b8ee111$0$14756$c3e8da3@news.astraweb.com...

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





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@tadyatam.invalid]

Sid Elbow wrote in

news:4b8f0657$0$24276$c3e8da3@news.astraweb.com:



> Pegasus [MVP] wrote:

>>

>>

>> "Sid Elbow" wrote in message

>> news:4b8ee111$0$14756$c3e8da3@news.astraweb.com...

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

>

>

> 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

--

Replies to: Nherr1professor2doktor31109(at)Oyahoo(dot)Tcom

 

[Pegasus [MVP]]

"Sid Elbow" wrote in message

news:4b8f0657$0$24276$c3e8da3@news.astraweb.com...

> Pegasus [MVP] wrote:

>>

>>

>> "Sid Elbow" wrote in message

>> news:4b8ee111$0$14756$c3e8da3@news.astraweb.com...

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

>

>

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

Pegasus [MVP] wrote:



>> 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%



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]

Sid Elbow wrote:



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

"Sid Elbow" wrote in message

news:4b8fc89a$0$15668$c3e8da3@news.astraweb.com...

> Pegasus [MVP] wrote:

>

>>> 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%

>

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

me@tadyatam.invalid wrote:

> Sid Elbow wrote in



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



> 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\. 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]

Pegasus [MVP] wrote:

>

>

> "Sid Elbow" wrote in message



>>>> 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%

>>

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



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

"Sid Elbow" wrote in message

news:4b8fcfda$0$13640$c3e8da3@news.astraweb.com...

> Sid Elbow wrote:

>

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



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@tadyatam.invalid]

"Pegasus [MVP]" wrote in

news:e6$dv2$uKHA.3408@TK2MSFTNGP06.phx.gbl:



>

>

> "Sid Elbow" wrote in message

> news:4b8fcfda$0$13640$c3e8da3@news.astraweb.com...

>> Sid Elbow wrote:

>>

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

>

> 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

--

Replies to: Nherr1professor2doktor31109(at)Oyahoo(dot)Tcom

 

[Sid Elbow]

Pegasus [MVP] wrote:

>

> 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\) rather than the directory which contains the batch.

 

[Sid Elbow]

me@tadyatam.invalid wrote:



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

"Sid Elbow" wrote in message

news:002e57a3$0$4197$c3e8da3@news.astraweb.com...

> Pegasus [MVP] wrote:

>>

>>

>> "Sid Elbow" wrote in message

>

>>>>> 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%

>>>

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

>

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



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]

Pegasus [MVP] wrote:

>

>

> "Sid Elbow" wrote in message



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





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

"Sid Elbow" wrote in message

news:4b911aa2$0$12568$c3e8da3@news.astraweb.com...

> Pegasus [MVP] wrote:

>>

>>

>> "Sid Elbow" wrote in message

>

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

>

>

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



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]

Pegasus [MVP] wrote:



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



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

 

[Robbie Hatley]

"Sid Elbow" wrote:



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



Firstly, I don't think it matters if cbreak.exe is located in

same dir as the batch file. That's not where windows would look

for it, is it? Wouldn't it look first in the "current directory"

(which may not be where the batch file is at all!), then in

the directories listed in the %path% environment variable.



Here, I'll test that.....



I made a batch file called "path-test.bat" with one line:



template



I put both the batch file and the executable file "template.exe"

in folder "E:\CDDB", which is *not* in my %path% variable.

I set the current directory to "E:\Backups", which also is *not*

in %path%.



Now running batch file......



=============== COPIED FROM COMMAND CONSOLE =================



wd=E:\Backups

%path-test

'path-test' is not recognized as an internal or external command,

operable program or batch file.



wd=E:\Backups

%E:\CDDB\path-test



wd=E:\Backups

%template

'template' is not recognized as an internal or external command,

operable program or batch file.



wd=E:\Backups

wd=E:\Backups

%cd \CDDB



wd=E:\CDDB

%path-test



wd=E:\CDDB

%template



Directory #1: e:\CDDB

processing file path-test.bat

processing file template.exe

Finished processing files in this tree.

Directories processed: 1

Files examined: 2

Files bypassed: 0

Errors encountered: 0

Files successfully processed: 0



wd=E:\CDDB

%



=========== END COPY FROM COMMAND CONSOLE ==================



So no, it *doesn't* help to put the batch file and executable

in the same directory. The batch file does *not* look there

for files referenced inside the batch file. It looks only

in the current directory, and in %path%.



Also, some of the syntax you're using is totally alien to me.

Are you sure that's right? These two lines especially:



> mkdir "%~dp1cbreak"

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



THe "%~" doesn't look right to me.



--

Cheers,

Robbie Hatley

lonewolf at well dot com

www dot well dot com slant tilde lonewolf slant

 

[Sid Elbow]

Robbie Hatley wrote:



> Firstly, I don't think it matters if cbreak.exe is located in

> same dir as the batch file ....



Thanks for the response, Robbie but I think you probably need to read

the rest of the thread.



I've got a workable solution anyway.