spongeblink Posted May 30 Share Posted May 30 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: First, output a multi-line string, Get it through Automation Task "Strip Last Line", and show the result through a notification: 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 Link to comment
spongeblink Posted May 30 Author Share Posted May 30 (edited) I'm on Alfred 5.5 [2257] and macOS 14.5, both the latest as I was writing this. This behavior can be reproduced. Edit: I'm on Automation Tasks Version 2024.5 Edited May 30 by spongeblink Link to comment
Stephen_C Posted May 30 Share Posted May 30 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: (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
spongeblink Posted May 30 Author Share Posted May 30 @Stephen_C That's weird. Because I've just created the exact same workflow as yours and still get the same (wrong) result. 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: 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
Stephen_C Posted May 30 Share Posted May 30 (edited) @spongeblink we may have the key in this: 5 minutes ago, spongeblink said: No empty 6th line. My file did have an empty 6th line. When it does not I can reproduce your result. Edit: Yes, same version of Automation Tasks. Stephen Edited May 30 by Stephen_C spongeblink 1 Link to comment
Stephen_C Posted May 30 Share Posted May 30 I suspect this is something @vitor (Master of Automation Tasks) will pick up later. Stephen Link to comment
vitor Posted May 30 Share Posted May 30 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. Stephen_C 1 Link to comment
spongeblink Posted May 30 Author Share Posted May 30 Got it! Thanks for the explanation and the work, @vitor vitor 1 Link to comment
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now