Jump to content

Automation Task "Strip Last Line" Malfunctions


Recommended Posts

The Automation Task "Strip Last Line" doesn't seem to just strip the last line but the last 2. 

 

I've created this sample to demonstrate this:

image.thumb.png.b7a6aaa11499d64ec8469fc2803bbaeb.png

 

 

First, output a multi-line string,

 

 image.thumb.png.c5e061db8188bcf5079696abe3b93c56.png

 

Get it through Automation Task "Strip Last Line", and show the result through a notification:

image.png.c2edbb2246b1d25962ff97784dae8cfa.png

 

It's not just macOS not showing the third line. See the debugger:

 

[08:46:06.818] Test Workflow 2[Hotkey] Processing complete

[08:46:06.827] Test Workflow 2[Hotkey] Passing output '' to Run Script

[08:46:06.892] Test Workflow 2[Run Script] Processing complete

[08:46:06.899] Test Workflow 2[Run Script] Passing output '1

2

3

4' to Run Script

[08:46:06.901] Test Workflow 2[Run Script] Passing output '1

2

3

4' to Automation Task

[08:46:06.901] Test Workflow 2[Automation Task] Running task 'Strip Last Line' with arguments (

    "1\n2\n3\n4"

)

[08:46:06.907] Test Workflow 2[Automation Task] Processing complete

[08:46:06.908] Test Workflow 2[Automation Task] Passing output '1

2

' to Post Notification

Judging be the debugger info, the third line is empty.

 

And if you pass the same string through a Python script:

 

import sys

query = sys.argv[1]

sys.stdout.write("\n".join(query.splitlines()[:-1]))

 

The result would be

 

image.png.80c8c70c03496dfe8df5454496877ea2.png

 

 

Link to comment

The behaviour no doubt is reproduced the way you've constructed it (and I'm not for a moment suggesting there's anything wrong with what you've done). However, the behaviour is not universal.

 

This workflow:

CleanShot2024-05-30at08_02.49@2x.thumb.png.ad78e0533fc2b1d279da8b5ca7211750.png

(which feeds a text file containing 1, 2, 3, 4 and 5—each on a new line) gives the expected result.

 

Stephen

Link to comment

@Stephen_C That's weird. Because I've just created the exact same workflow as yours and still get the same (wrong) result. 

image.thumb.png.8e5e820249f0a086c226d91bfdf93c0c.png

 

The debugger info:

 

[15:19:24.080] Test Workflow 2[Keyword] Processing complete

[15:19:24.083] Test Workflow 2[Keyword] Passing output '' to Automation Task

[15:19:24.084] Test Workflow 2[Automation Task] Running task 'File Contents' with arguments (

    "/Users/[edited for privacy concern]/x.txt"

)

[15:19:24.090] Test Workflow 2[Automation Task] Processing complete

[15:19:24.091] Test Workflow 2[Automation Task] Passing output '1

2

3

4

5' to Automation Task

[15:19:24.092] Test Workflow 2[Automation Task] Running task 'Strip Last Line' with arguments (

    "1\n2\n3\n4\n5"

)

[15:19:24.099] Test Workflow 2[Automation Task] Processing complete

[15:19:24.101] Test Workflow 2[Automation Task] Passing output '1

2

3

' to Large Type

 

My file looks like this:

image.png.41e2a9cf047701705fe83909e2172e50.png

 

5 lines, 5 numbers. No empty 6th line. 

 

Also, are you using the same Alfred and Automation Tasks version (mine is 2024.5) as me?

Link to comment

You are both correct and the behaviour is both consistent and easy to explain once you learn it. I read the original post last night but it was already pretty late so I decided it was best to (literally) sleep on it rather than send a tired reply.


Essentially what’s happening is that newlines are meaningful and Unix¹ tools act under that assumption. So when you have 1\n2\n3\n4, technically the termination is incorrect and should be 4\n. Like so many other things in computing, there’s no outright right or wrong answer, it depends. For instance, the Python example above always eats the final newline, whether it was originally there or not. If you used that output to write to a file, you’d have an invalid² text file. On the other hand in JavaScript you have to split on \n, so it will give you an empty last item depending on if the last newline is there or not. And in Ruby… Ah, you get the picture.


All that said, other Automation Tasks which could have different results depending on the trailing newlines (such as Text Metrics) already correct for these cases to conform to expectations³ so this one will as well. Note that the result will always output a newline at the end, as per the more “correct” Unix interpretation (you can always trim that with another object if absolutely necessary). I have working code for it since early this morning, but since it’s not urgent (as you have a workaround) I’ll think on it a bit more in case I forgot something.


Thank you for reporting.


¹ The type of operating system that macOS is.


² Again, in the technical sense. macOS would know how to read it anyway but some tools like wc would give different results.


³ I understand it’s frustrating trying to debug something which depends on invisible characters.

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...