#1277 CreateShortcut \t in target file name causes problems (NSIS 3.08)

[Greg Smith]

When my target file is called ...\Support\Try1432.exe and I use the following commands:

    StrCpy $1 "$szProgramDir\Support"
    SetOutPath "$1"
    CreateShortCut "$0\Try 1401 test program.lnk" "$1\try1432.exe" \
              "" "" "" SW_SHOWNORMAL "" "1401 test program"

A shortcut is created, but the file type in Explorer is set to File not Shortcut, and it does not work. Changing the target name to "$1\Try1432.exe" fixes the problem. Either there is some sort of case sensitivity problem or maybe the \t is being translated to Tab somewhere.

If this is a known effect perhaps it would be worth adjusting the documentation to warn about this? I have seen other reports of problems where folks had to double the \ to get this to work and did not understand why... perhaps they had a similar character substitution problem?

[Greg Smith]

OK. A little more adjustment shows that:

    StrCpy $1 "$szProgramDir\Support"
    SetOutPath "$1"
    CreateShortCut "$0\Try 1401 test program.lnk" "$1\\try1432.exe" \
              "" "" "" SW_SHOWNORMAL "" "1401 test program"

fixes the problem. This suggests to me that whatever process is used to add the shortcut is passing the file name through code that translates at least \t (and likely other combinations).

[Anders]

I can't reproduce this with

RequestExecutionLevel User

Section
GetFullPathName $0 "$exedir"
StrCpy $1 $0

SetOutPath "$1"
CreateShortCut "$0\Try 1401 test program.lnk" "$1\try1432.exe" \
              "" "" "" SW_SHOWNORMAL "" "1401 test program"

ExecWait 'cmd /c copy /v "$exepath" "$1\try1432.exe"' ; make sure the target exists
SectionEnd

Does try1234.exe exist before you create the shortcut? (Ideally it should)

Windows version?

Encoding of your .nsi? UTF-8 BOM? (Mine was plain ASCII with no BOM)

[Greg Smith]

On 21/12/2021 11:41, Anders wrote:

I can't reproduce this with

RequestExecutionLevel User

Section
GetFullPathName $0 "${FILE}.."
StrCpy $1 $0

SetOutPath "$1"
CreateShortCut "$0\Try 1401 test program.lnk" "$1\try1432.exe" \
"" "" "" SW_SHOWNORMAL "" "1401 test program"

ExecWait 'cmd /c copy /v "$exepath" "$1\try1432.exe"' ; make sure the target exists
SectionEnd

Does try1234.exe exist before you create the shortcut? (Ideally it should)

Yes. As I said, changing the target.file name to use ...\T... or
...\t... fixed the problem.

Windows version?

Windows 10 Pro 20H2 64-bit

Encoding of your .nsi? UTF-8 BOM? (Mine was plain ASCII with no BOM)

According to NotePad++ UTF8  no BOM (but only holds ASCII AFAIK).

I sent you another comment in which changing "$0\try1432.exe" to
"$0\try1432.exe" fixed the effect, so I am presuming that it is
something to do with \t (and I presume \n and \r etc) being treated
specially somewhere. I have seen reports of problems with CreateShortCut
that were 'fixed' by using \ rather than \ in the target.file path (but
I cannot find the reference today).

Thank you for your reply.

---

[Anders]

$\t is the escape but that does not happen on my end with $1\t. Can you compile the code I posted and upload the compiled installer.

Your e-mail software might be eating some of your slashes, edit your post on Sourceforge.

[Greg Smith]

I am editing posts on SourceForge and what I see looks as intended. What I am doing is closer to:

Unicode true
RequestExecutionLevel Admin
Outfile "try1432.exe"

!include MUI2.nsh               # Modern user interface stuff

!define MUI_PAGE_CUSTOMFUNCTION_PRE InstallPage_leave
!insertmacro MUI_PAGE_INSTFILES


Section

SectionEnd

Function InstallPage_leave
GetFullPathName $0 "$exedir"

SetShellVarContext all 
StrCpy $1 "$SMPROGRAMS\TryTest"

SetOutPath "$1"
CreateShortCut "$1\Try 1401 test program.lnk" "$0\try1432.exe" \
              "" "" "" SW_SHOWNORMAL "" "1401 test program"
FunctionEnd

However, this works fine, as you say.

The actual script I am using is in 3 files with a total of 2400 lines or so and also includes some details of our software protection, so I cannot let it out... also I'm sure you have better things to do than look at a dodgy script. The script does include calls into proprietary DLLs, so it is possible that I have screwed something up with the calling conventions that has upset things.

In any case, I have a work around of using two back-slashes. I suspect that whatever Windows mechanism is used to create the shortcut is processing the path in some unexpected manner, but why we cannot reproduce this with simplified code defeats me.

Thank you for taking the time to try to reproduce this. If I find anything useful I will let you know.

[Anders]

Then ideally you should comment out parts of your script until it starts working. I can't really help without code that reproduces the error.

If you know how to debug you can set a breakpoint on the code that calls IShellLink and look at the path there.