How to create a folder inside all first-level subfolders?

[machone]

I've got a directory structure with a main folder and several levels of subfolders. I need to be able to create a same-named folder (i.e. \temp\) in every subfolder (1 level down) but not in any sub-subfolders (2+ levels down). I've been trying different approaches with no luck so far.. Does anyone have a quick solution for this?

Basically, I want to create

\Main\SubFolder\temp\

inside every 'SubFolder', but I do not want it to create

\Main\SubFolder\Sub-SubFolder\temp\

[Squashman]

Code: Select all

@echo off
pushd c:\main
FOR /F "delims=" %%G in ('dir /ad /b') do mkdir "%%G\temp"
popd

[machone]

Thanks! I had come up with this, which seems to work so far:

@echo off
for /d %%a in ( ".\*" ) do (
md "%%a\temp" 2>nul
)

Do you see any potential issues with the way I arrived at the solution?

[foxidrive]

I would use Squashman's solution myself.

The /D and /R options of FOR do have bugs, and a FOR /F can always be used instead.

[machone]

Ok, thanks!

[Aacini]

The /D and /R options of FOR do have bugs, and a FOR /F can always be used instead.

Excuse me. I always suggest to avoid using FOR /F that execute another command (like DIR) if the base FOR (not /F) is enough; this is because the former is slower. However, if /D and /R options do have bugs, then this is not a good idea.

Could you describe the bugs and show a small example that reproduce they? Thanks!

Antonio

[foxidrive]

The /D and /R options of FOR do have bugs, and a FOR /F can always be used instead.

Could you describe the bugs and show a small example that reproduce they? Thanks!

Antonio

They involved path names with spaces/characters in some fashion, when specifying a path in the FOR command. I don't have an example - it was discovered some years ago and discussed in alt.msdos.batch.nt but I don't have a link to the discussion.

[Ed Dyreen]

Hi foxi,

They involved path names with spaces/characters in some fashion, when specifying a path in the FOR command. I don't have an example - it was discovered some years ago and discussed in alt.msdos.batch.nt but I don't have a link to the discussion.

I use For /D /R all the time, but a statement which can't be proven is not worth mentioning.

Hope you can recall it, thanks,
ed

[foxidrive]

Hi foxi,

They involved path names with spaces/characters in some fashion, when specifying a path in the FOR command. I don't have an example - it was discovered some years ago and discussed in alt.msdos.batch.nt but I don't have a link to the discussion.

I use For /D /R all the time, but a statement which can't be proven is not worth mentioning.

Find the discussion and you will find the proof you desire.

All I need to know is that I tested it at the time and verified the failure, so I avoid using /R with a specified path.

[Liviu]

The /D and /R options of FOR do have bugs, and a FOR /F can always be used instead.

Could you describe the bugs and show a small example that reproduce they?

I asked the same question a few times, and the only answers I got boiled down to "there have been issues reported elsewhere, don't remember the details, but trust us that it's well known that for/d/r loops are unreliable". Almost like a self-referential myth

I've run my own research on the topic, summarized at https://groups.google.com/group/alt.msdos.batch.nt/msg/a801b8a1904942cd?hl=en. In brief, there are a couple of corner cases which IMHO are not bugs, and one reported bug (in a rather arcane scenario where the body of the loop modifies the directory tree that for/r is operating on) which I was not able to duplicate.

Liviu

P.S. The continuing recommendation to, for example, use "for /f in ('dir /ad')" instead of the builtin "for /d" is one reason behind the widespread misconception that batch language cannot handle unicode pathnames.

[foxidrive]

For /D doesn't have the issue as it cannot have a path specified. It was FOR /R with a specified path.

Maybe it is related to the short filename bug, as it doesn't affect every instance of it.

[Liviu]

For /D doesn't have the issue as it cannot have a path specified. It was FOR /R with a specified path.

Yet a few posts above you advised against "for /d" and recommended "for /f in ('dir /ad /b')" instead.

To be clear, I am not saying that you are wrong about possible for/d/r issues, in fact I'd be very interested to find out what those are. But so far I have yet to see any tangible proof thereof.

Maybe it is related to the short filename bug, as it doesn't affect every instance of it.

There is a longstanding SFN bug, indeed, partially but not fully fixed as of Win7 (http://groups.google.com/group/alt.msdos.batch.nt/browse_frm/thread/afb023e1792881b5/85379bd32ede38b6?hl=en#85379bd32ede38b6). However, that's irrelevant in most cases, including the one here, and doesn't warrant a blanket for/d/r censure.

Liviu

[Squashman]

What I find amusing is that Foxidrive and Liviu both posted in that thread.

[carlos]

In http://ss64.com/nt/for_d.html says:

The option /d /r is undocumented and somewhat buggy, it fails for root folders

[Liviu]

The option /d /r is undocumented and somewhat buggy, it fails for root folders

My "for/d/r" notation was just shorthand for "for/d or for/r" as I hoped was clear in the context of this thread.

Besides, I wish ss64 provided some details on how "for /d /r" exactly fails for root folders.