Bug 145774

Summary:	Find and Replace (with regular expression option): ^ is not found in search
Product:	LibreOffice	Reporter:	Salek Talangi <salek.talangi>
Component:	Calc	Assignee:	Not Assigned <libreoffice-bugs>
Status:	RESOLVED DUPLICATE
Severity:	normal	CC:	buzea.bogdan, chris, miguelangelrv
Priority:	medium
Version:	7.1.6.2 release
Hardware:	x86-64 (AMD64)
OS:	Windows (All)
Whiteboard:
Crash report or crash signature:		Regression By:
Bug Depends on:
Bug Blocks:	146076
Attachments:	Screenshot displaying the problem

Description Salek Talangi 2021-11-19 10:19:58 UTC

Created attachment 176358 [details]
Screenshot displaying the problem

Problem description: I'm trying to change a doc that looks like this and found an issue with rexexp find while doing so.

Example:
ABC
ABC
ABC

I want to add XX- to the beginning of the cells. Normally I'd do it like this:
Search: ^
Replace: XX-

but this does not work, as ^ does not find anything. ^A does, but then I'd be deleting the A.

Search: ^(.*)
Replace: XX-$1
works, but seems like a workaround.

A single $ as search string to add to the end of the cells does work though.

So the problem seems to be with the single ^ only.



Version: 7.1.6.2 (x64) / LibreOffice Community
Build ID: 0e133318fcee89abacd6a7d077e292f1145735c3
CPU threads: 8; OS: Windows 10.0 Build 19043; UI render: Skia/Raster; VCL: win
Locale: de-DE (de_DE); UI: de-DE
Calc: threaded

Comment 1 Michael Warner 2021-11-19 15:32:25 UTC

Thanks for writing this report, but I think this is a duplicate of bug 135538.

*** This bug has been marked as a duplicate of bug 135538 ***

Comment 2 Salek Talangi 2021-11-19 15:59:25 UTC

Hi, I'm not sure this is true - or the other bug report needs an update.
$ is working fine, and I think this is a zero length match as well.

Comment 3 Michael Warner 2021-11-20 14:25:23 UTC

Well, I suspect it's the same root cause. But we can change it to just See Also for now. Either way, I can confirm that $ works and ^ does not. 

Version: 7.2.2.2 / LibreOffice Community
Build ID: 02b2acce88a210515b4a5bb2e46cbfb63fe97d56
CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: gtk3
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: threaded

Comment 4 m_a_riosv 2024-03-11 09:50:18 UTC

*** Bug 160118 has been marked as a duplicate of this bug. ***

Comment 5 m_a_riosv 2024-03-11 09:53:15 UTC

(In reply to Salek Talangi from comment #2)
> Hi, I'm not sure this is true - or the other bug report needs an update.
> $ is working fine, and I think this is a zero length match as well.

$ is no empty, there is at least carry return or a line break.

Comment 6 Salek Talangi 2024-03-11 10:25:37 UTC

(In reply to m_a_riosv from comment #5)
> $ is no empty, there is at least carry return or a line break.

Why should there be a carriage return or a line break if I don't enter one? But also, this is not the problem.
The problem is with ^ not matching anything.

Comment 7 Mike Kaganski 2024-05-03 03:33:28 UTC

This is exactly tdf#135538. The special processing of $ is unrelated, and just distorts the perspective. This whole problem is about inability to find zero-length match, with both elaborate pre/postconditions, or special cases of pre/postconditions like ^ or \b are all nor handled by their own.

*** This bug has been marked as a duplicate of bug 135538 ***