Tell me more ×
Stack Overflow is a question and answer site for professional and enthusiast programmers. It's 100% free, no registration required.

I want to split a string in two parts, without using any for loop.

For example, I have the string in a variable:

str=45:abc

I want to get 45 in a variable and abc in another variable. Is it possible in batch file?

pattern is like somenumber:somestring

share|improve this question

3 Answers

up vote 3 down vote accepted

You could split the str with different ways.

The for loop, you don't want use it.

The trailing part is easy with the * (match anything until ...)
set "var2=%str:*:=%"

The leading part can be done with a nasty trick
set "var1=%str::="^&REM #%

The caret is needed to escape the ampersand,
so effectivly the colon will be replaced by "&REM # So in your case you got the line after replacing
set "var1=4567"&REM #abcde
And this is splitted into two commands

set "var1=4567"
REM #abcde` 

And the complete code is here:

set "str=4567:abcde"
echo %str%
set "var1=%str::="^&REM #%
set "var2=%str:*:=%"
echo var1=%var1% var2=%var2%

Edit 2: More stable leading part

Thanks Dave for the idea to use a linefeed.
The REM technic isn't very stable against content with quotes and special characters.
But with a linefeed trick there exists a more stable version which also works when the split argument is longer than a single character.

@echo off
setlocal enableDelayedExpansion
set ^"str=456789#$#abc"
for /F "delims=" %%a in (^"!str:#$#^=^

!^") do (
  set "lead=%%a"
  goto :break
)
:break
echo !lead!

Solution 3: Adpated dbenhams answer

Dbenham uses in his solution a linefeed with a pipe.
This seems a bit over complicated.
As the solution uses the fact, that the parser removes the rest of the line after an unescaped linefeed (when this is found before or in the special character phase).

At first the colon character is replaced to a linefeed with delayed expansion replacement.
That is allowed and the linefeed is now part of the variable.
Then the line set lead=%lead% strips the trailing part.
It's better not to use the extended syntax here, as set "lead=%lead%" would break if a quote is part of the string.

setlocal enableDelayedExpansion
set "str=45:abc"
set ^"lead=!str::=^

!"
set lead=%lead%
echo "!lead!"
share|improve this answer
^&REM # ... could you please explain it. – user1511510 Jan 31 at 9:08
I edited the text – jeb Jan 31 at 11:07
+1 This is awesome jeb, much better than the version I came up with (I didn't bother posted after seeing yours :) ) This also works with just ^&REM - without the hash. – Bali C Jan 31 at 11:38
@BaliC The hash is for some nasty contents like /? – jeb 2 days ago
Regarding Edit 2 - I thought the whole point was to avoid use of FOR ;-) – dbenham 1 hour ago
show 1 more comment

You can try this . If its fixed that numbers to left of the colon will be always 2 & to the right will be 3. Then following code should work assuming your str has the value.

set "str=45:abc"
echo %str%
set var1=%str:~0,2%
set var2=%str:~3,3%
echo %var1% %var2%

Keep me posted. :)

share|improve this answer
no... it is not fixed...always varible... :( – user1511510 Jan 31 at 8:27
So what pattern it might be? – Gaurav Kolarkar_InfoCepts Jan 31 at 8:28
patter is like somenumber:somestring ? – user1511510 Jan 31 at 8:31
@user1511510 The format thing is important here, it should be added to the question – jeb Jan 31 at 8:53
What is the problem you are facing with for loop? – Gaurav Kolarkar_InfoCepts Jan 31 at 8:54

It seems pointless to avoid using a FOR loop, but it does make the problem interesting.

As jeb has pointed out, getting the trailing part is easy using !str:*:=!.

The tricky bit is the leading part. Here is an alternative to jeb's solution.

You can insert a linefeed into a variable in place of the : using the following syntax

setlocal enableDelayedExpansion
set "str=45:abc"
echo !str::=^

!

--OUTPUT--

45
abc

The empty line above the last ! is critical.

I'm not sure why, but when the output of the above is piped to a command, only the first line is preserved. So the output can be piped to a FINDSTR that matches any line, and that result directed to a file that can then be read into a variable using SET /P

Here is a complete solution:

@echo off
setlocal enableDelayedExpansion
set "str=45:abc"
echo(!str::=^

!|findstr "^" >test.tmp
<test.tmp set /p "var1="
del test.tmp
set "var2=!str:*:=!"
echo var1=!var1!  var2=!var2!

Update

I believe I've mostly figured out why the 2nd line is stripped from the output :)

It has to do with how pipes are handled by Windows cmd.exe with each side being processed by a new CMD.EXE thread. See Why does delayed expansion fail when inside a piped block of code? for a related question with a great answer from jeb.

Just looking at the left side of the piped command, I believe it is parsed (in memory) into a statement that looks like

C:\Windows\system32\cmd.exe /S /D /c" echo {delayedExpansionExpression}"

I use {delayedExpansionExpression} to represent the multi-line search and replace expansion that has not yet occurred.

Next, I think the variable expression is actually expanded and the line is broken in two by the search and replace:

C:\Windows\system32\cmd.exe /S /D /c" echo 43
abc"

Only then is the command executed, and by normal cmd.exe rules, the command ends at the linefeed. The quoted command string is missing the end quote, but the parser doesn't care about that.

The part I am still puzzled by is what happens to the abc"? I would have thought that an attempt would be made to execute it, resulting in an error message like 'abc"' is not recognized as an internal or external command, operable program or batch file. But instead it appears to simply get lost in the ether. note - jeb's 3rd comment explains why :)

Safe version without FOR

My original solution will not work with a string like "&|<". Here is a variation without FOR that should work with nearly any string, except for string length limits and trailing control chars will be stripped from leading part.

@echo off
setlocal enableDelayedExpansion
set "str=this & that:cats & dogs"
set ^"str2=!str::=^

!^"
cmd /v:on /c echo ^^!str2^^!|findstr /v "$" >test.tmp
<test.tmp set /p "var1="
del test.tmp
set "var2=!str:*:=!"
echo var1=!var1!  var2=!var2!

I delay the expansion until the new CMD thread, and I use a quirk of FINDSTR regex that $ only matches lines that end with <cr>. The first line doesn't have it and the second does. The /v option inverts the result.

share|improve this answer
+1: Good idea to use a linefeed here, but I suppose your analysis is wrong. The {delayedExpansionExpression} has already occoured when the cmd /S/D/c is started` as in the new cmd-context the delayed expanson is disabled (There is the rule or bug, that delayed expansion is done in the batch context when it's only a single line without parenthesis). I tested it with %%cmdcmdline%%. The stripping of the second part is done by the rule that parsing stops if an unescaped linefeed is found in line (in a block it's different) – jeb 4 hours ago
Thanks for the linefeed idea, I added another solution to my answer – jeb 4 hours ago
@jeb - I think you misunderstood my explanation. I know the delayed expansion happens in the parent batch and not in the new cmd thread. Both lines are preserved if steps are taken to postpone the expansion until within new thread. However, I'm assuming the parser prepares the cmd /S/D/c statement before the delayed expansion, then the statement is expanded, then it is executed in the new thread. I also know the cmd /S/D/c... will stop at the first linefeed, so only 43 is piped to FINDSTR. But why no error from attempt to execute abc"? Where does abc" go? – dbenham 1 hour ago
Ok I misunderstood your explanation :-) The abc" is hard removed from the line by the unescaped linefeed. It's the same as in echo 123%LF%abc. The rest is removed by the parser after the percent expansion, but before the sepcial character phase begins – jeb 48 mins ago
@jeb - ahh, simple enough. Thanks :-) – dbenham 33 mins ago

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.