Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #200615 > unrolled thread

Scribus has stopped importing PDF files

Back to article view | Back to linux.debian.user

Contents

  Scribus has stopped importing PDF files Gary Dale <garyndp@gmail.com> - 2018-09-25 23:00 +0200
    question about ls Long Wind <longwind2@yahoo.com> - 2018-09-26 00:30 +0200
      Re: question about ls Ben Caradoc-Davies <ben@transient.nz> - 2018-09-26 00:40 +0200
        Re: question about ls Long Wind <longwind2@yahoo.com> - 2018-09-26 01:00 +0200
          Re: question about ls Long Wind <longwind2@yahoo.com> - 2018-09-26 01:00 +0200
            Re: question about ls Ben Caradoc-Davies <ben@transient.nz> - 2018-09-26 01:20 +0200
              Re: question about ls Kent West <westk@acu.edu> - 2018-09-27 15:00 +0200
                Re: question about ls Greg Wooledge <wooledg@eeg.ccf.org> - 2018-09-27 15:20 +0200
                  Re: question about ls Richard Hector <richard@walnut.gen.nz> - 2018-09-28 08:00 +0200
                    Re: question about ls Ionel Mugurel Ciobîcă <I.M.Ciobica@gmail.com> - 2018-09-28 09:10 +0200
                      Re: question about ls Greg Wooledge <wooledg@eeg.ccf.org> - 2018-09-28 14:30 +0200
                        Re: question about ls Richard Hector <richard@walnut.gen.nz> - 2018-09-28 16:40 +0200
                  Re: question about ls Virgo Pärna <virgo.parna@mail.ee> - 2018-10-03 14:10 +0200
                    Re: question about ls Greg Wooledge <wooledg@eeg.ccf.org> - 2018-10-03 15:00 +0200
                Re: question about ls David Wright <deblis@lionunicorn.co.uk> - 2018-09-27 16:00 +0200
                  Re: question about ls Greg Wooledge <wooledg@eeg.ccf.org> - 2018-09-27 16:10 +0200
                    Re: question about ls David Wright <deblis@lionunicorn.co.uk> - 2018-09-27 16:30 +0200
                    Re: question about ls Michael Stone <mstone@debian.org> - 2018-09-27 17:10 +0200
                      Re: question about ls <tomas@tuxteam.de> - 2018-09-28 09:00 +0200
                        Re: question about ls Michael Stone <mstone@debian.org> - 2018-09-28 12:50 +0200
                    Re: question about ls <tomas@tuxteam.de> - 2018-09-28 09:00 +0200
      Re: question about ls Greg Wooledge <wooledg@eeg.ccf.org> - 2018-09-27 14:40 +0200
        Re: question about ls Gene Heskett <gheskett@shentel.net> - 2018-09-27 17:00 +0200
          Re: question about ls Greg Wooledge <wooledg@eeg.ccf.org> - 2018-09-27 17:10 +0200
    Re: Scribus has stopped importing PDF files rv riveravaldez <riveravaldezmail@gmail.com> - 2018-09-28 01:40 +0200

Page 1 of 2  [1] 2  Next page →

#200615 — Scribus has stopped importing PDF files

For the last few days, some Scribus documents I work with have stopped 
accepting PDF files within image frames. Prior to this, they would 
display a preview. Now new image frames that I create show just the file 
name, but some older frames within the document still show the preview.

When I export the document as a PDF, the frames that just display the 
file name export as empty/blank. The older frame that shows a preview 
causes the export to stop with an error saying it was unable to load the 
image.

I'm not sure if this is related to something in the PDFs or not. However 
it is happening on two documents I am working on.

[toc] | [next] | [standalone]

#200616 — question about ls

[Multipart message — attachments visible in raw view] — view raw

can ls show number of items in a folder?Thanks! 

    On Wednesday, September 26, 2018 4:51 AM, Gary Dale <garyndp@gmail.com> wrote:
 

 For the last few days, some Scribus documents I work with have stopped 
accepting PDF files within image frames. Prior to this, they would 
display a preview. Now new image frames that I create show just the file 
name, but some older frames within the document still show the preview.

When I export the document as a PDF, the frames that just display the 
file name export as empty/blank. The older frame that shows a preview 
causes the export to stop with an error saying it was unable to load the 
image.

I'm not sure if this is related to something in the PDFs or not. However 
it is happening on two documents I am working on.



   

[toc] | [prev] | [next] | [standalone]

#200617 — Re: question about ls

On 26/09/2018 10:27, Long Wind wrote:
> can ls show number of items in a folder?Thanks!

I use:

ls -1 | wc -l

To include items whose names start with ".", add the "a" or "A" argument 
to ls ("man ls" for details).

For more advanced searches (recursive or filtering on file type), I use 
find.

Kind regards.

-- 
Ben Caradoc-Davies <ben@transient.nz>
Director
Transient Software Limited <https://transient.nz/>
New Zealand

[toc] | [prev] | [next] | [standalone]

#200619 — Re: question about ls

[Multipart message — attachments visible in raw view] — view raw

Thanks for your quick reply!
do you mean "ls -l | wc -l"it should be letter l, not number 1
 

    On Wednesday, September 26, 2018 6:34 AM, Ben Caradoc-Davies <ben@transient.nz> wrote:
 

 On 26/09/2018 10:27, Long Wind wrote:
> can ls show number of items in a folder?Thanks!

I use:

ls -1 | wc -l

To include items whose names start with ".", add the "a" or "A" argument 
to ls ("man ls" for details).

For more advanced searches (recursive or filtering on file type), I use 
find.

Kind regards.

-- 
Ben Caradoc-Davies <ben@transient.nz>
Director
Transient Software Limited <https://transient.nz/>
New Zealand



   

[toc] | [prev] | [next] | [standalone]

#200620 — Re: question about ls

[Multipart message — attachments visible in raw view] — view raw

sorry! you're right.
after checking ls manual, i find ls has option -1
 

    On Wednesday, September 26, 2018 6:52 AM, Long Wind <longwind2@yahoo.com> wrote:
 

 Thanks for your quick reply!
do you mean "ls -l | wc -l"it should be letter l, not number 1
 

    On Wednesday, September 26, 2018 6:34 AM, Ben Caradoc-Davies <ben@transient.nz> wrote:
 

 On 26/09/2018 10:27, Long Wind wrote:
> can ls show number of items in a folder?Thanks!

I use:

ls -1 | wc -l

To include items whose names start with ".", add the "a" or "A" argument 
to ls ("man ls" for details).

For more advanced searches (recursive or filtering on file type), I use 
find.

Kind regards.

-- 
Ben Caradoc-Davies <ben@transient.nz>
Director
Transient Software Limited <https://transient.nz/>
New Zealand



   

   

[toc] | [prev] | [next] | [standalone]

#200622 — Re: question about ls

On 26/09/2018 10:55, Long Wind wrote:
> sorry! you're right.
> after checking ls manual, i find ls has option -1

Note also that ls will behave like it has the "-1" option if its output 
is piped to another command, even without this option. I like to use the 
"-1" option even in this case because it is what I mean (counting 
entries one per line).

Kind regards,

-- 
Ben Caradoc-Davies <ben@transient.nz>
Director
Transient Software Limited <https://transient.nz/>
New Zealand

[toc] | [prev] | [next] | [standalone]

#200674 — Re: question about ls

[Multipart message — attachments visible in raw view] — view raw

On Tue, Sep 25, 2018 at 6:14 PM Ben Caradoc-Davies <ben@transient.nz> wrote:

> On 26/09/2018 10:55, Long Wind wrote:
> > sorry! you're right.
> > after checking ls manual, i find ls has option -1
>
> Note also that ls will behave like it has the "-1" option if its output
> is piped to another command, even without this option. I like to use the
> "-1" option even in this case because it is what I mean (counting
> entries one per line).
>
>
But also note the difference when using the letter "l" vs the numeral "1":

westk@westkbox:/opt$ ls -la | wc
     7      56     321
westk@westkbox:/opt$ ls -1a | wc
     6       6      54

The difference is that the letter includes the total count of blocks used
at the top of the list (adding one to the count), whereas the numeral does
not.



-- 
Kent West                    <")))><
Westing Peacefully - http://kentwest.blogspot.com

[toc] | [prev] | [next] | [standalone]

#200676 — Re: question about ls

On Thu, Sep 27, 2018 at 07:55:56AM -0500, Kent West wrote:
> But also note the difference when using the letter "l" vs the numeral "1":
> 
> westk@westkbox:/opt$ ls -la | wc
>      7      56     321
> westk@westkbox:/opt$ ls -1a | wc
>      6       6      54

But also note that using ls -l gives a completely wrong answer.

wooledg:~$ mkdir /tmp/x && cd "$_"
wooledg:/tmp/x$ touch $'this\nis\none\nfile'
wooledg:/tmp/x$ ls -l | wc -l
5

Thus, <https://mywiki.wooledge.org/BashFAQ/004>.

[toc] | [prev] | [next] | [standalone]

#200694 — Re: question about ls

[Multipart message — attachments visible in raw view] — view raw

On 28/09/18 1:14 AM, Greg Wooledge wrote:
> On Thu, Sep 27, 2018 at 07:55:56AM -0500, Kent West wrote:
>> But also note the difference when using the letter "l" vs the numeral "1":
>>
>> westk@westkbox:/opt$ ls -la | wc
>>      7      56     321
>> westk@westkbox:/opt$ ls -1a | wc
>>      6       6      54
> 
> But also note that using ls -l gives a completely wrong answer.
> 
> wooledg:~$ mkdir /tmp/x && cd "$_"
> wooledg:/tmp/x$ touch $'this\nis\none\nfile'
> wooledg:/tmp/x$ ls -l | wc -l
> 5

Eww. Tab completion also gets screwed up by this:

richard@zircon:~/test$ rm <tab>
file  is    one   this

.. but you can't actually complete from any of those.

Richard

[toc] | [prev] | [next] | [standalone]

#200697 — Re: question about ls

On 28-09-2018, at 17h 52'07", Richard Hector wrote about "Re: question about ls"
> 
> Eww. Tab completion also gets screwed up by this:
> 
> richard@zircon:~/test$ rm <tab>
> file  is    one   this
> 
> .. but you can't actually complete from any of those.
> 

Hi,

I am not a bash user, but if I try what you suggest, Richard, I see
the file as "this^Jis^Jone^Jfile" with tab completion (on one line).


Ionel

P.S. What doesn't mean the $'foo\nbar' construction? In tcsh it says
"Illegal variable name." and in history it is recalled as $\'foa\nbar'
instead. I see that ksh also behave as bash with this $'foo\nbar'
entity.

[toc] | [prev] | [next] | [standalone]

#200714 — Re: question about ls

On Fri, Sep 28, 2018 at 09:06:59AM +0200, Ionel Mugurel Ciobîcă wrote:
> On 28-09-2018, at 17h 52'07", Richard Hector wrote about "Re: question about ls"
> > Eww. Tab completion also gets screwed up by this:
> > 
> > richard@zircon:~/test$ rm <tab>
> > file  is    one   this

You're probably using "bash-completion", which is a separate project
from bash, and is known to have many flaws.

> I am not a bash user, but if I try what you suggest, Richard, I see
> the file as "this^Jis^Jone^Jfile" with tab completion (on one line).

And in regular bash (without bash-completion), I see this:

wooledg:/tmp/x$ rm 'this
is
one
file' _

where _ is the cursor.

> P.S. What doesn't mean the $'foo\nbar' construction? In tcsh it says
> "Illegal variable name." and in history it is recalled as $\'foa\nbar'
> instead. I see that ksh also behave as bash with this $'foo\nbar'
> entity.

In bash, $'...' is a special form of quoting which acts like
single-quoting except that certain backslash+letter sequences are expanded
in a way that's similar to C's strings.  For example, \n expands to a
newline character, and \t to a tab.  See the man page for full details.

wooledg:~$ printf %s $' \t\n' | od -tx1 -An
 20 09 0a

It's the cleanest way to specify special characters in an argument string
or a variable assignment.

[toc] | [prev] | [next] | [standalone]

#200718 — Re: question about ls

[Multipart message — attachments visible in raw view] — view raw

On 29/09/18 12:21 AM, Greg Wooledge wrote:
> On Fri, Sep 28, 2018 at 09:06:59AM +0200, Ionel Mugurel Ciobîcă wrote:
>> On 28-09-2018, at 17h 52'07", Richard Hector wrote about "Re: question about ls"
>>> Eww. Tab completion also gets screwed up by this:
>>>
>>> richard@zircon:~/test$ rm <tab>
>>> file  is    one   this
> You're probably using "bash-completion", which is a separate project
> from bash, and is known to have many flaws.
> 
>> I am not a bash user, but if I try what you suggest, Richard, I see
>> the file as "this^Jis^Jone^Jfile" with tab completion (on one line).
> And in regular bash (without bash-completion), I see this:
> 
> wooledg:/tmp/x$ rm 'this
> is
> one
> file' _
> 
> where _ is the cursor.
> 

Seems likely. Maybe I should file a bug ... but the list is already a
mile long, and it's a (hopefully) unusual case that I've never run into
in ordinary usage.

Richard

[toc] | [prev] | [next] | [standalone]

#200853 — Re: question about ls

On Thu, 27 Sep 2018 09:14:00 -0400, Greg Wooledge <wooledg@eeg.ccf.org> wrote:
> But also note that using ls -l gives a completely wrong answer.
>
> wooledg:~$ mkdir /tmp/x && cd "$_"
> wooledg:/tmp/x$ touch $'this\nis\none\nfile'
> wooledg:/tmp/x$ ls -l | wc -l
> 5
>

	What about 'ls -1b | wc -l'?

-- 
Virgo Pärna 
virgo.parna@mail.ee

[toc] | [prev] | [next] | [standalone]

#200859 — Re: question about ls

On Wed, Oct 03, 2018 at 12:01:02PM +0000, Virgo Pärna wrote:
> On Thu, 27 Sep 2018 09:14:00 -0400, Greg Wooledge <wooledg@eeg.ccf.org> wrote:
> > But also note that using ls -l gives a completely wrong answer.
> >
> > wooledg:~$ mkdir /tmp/x && cd "$_"
> > wooledg:/tmp/x$ touch $'this\nis\none\nfile'
> > wooledg:/tmp/x$ ls -l | wc -l
> > 5
> >
> 
> 	What about 'ls -1b | wc -l'?

Not portable, but if you're willing to write scripts that only work with
GNU coreutils installed, maybe an option.  You'd probably want to add -A
as well.

How about just using one of the bash builtin methods that are presented
on <https://mywiki.wooledge.org/BashFAQ/004>?  Not only are they portable
(so long as bash is installed), but they don't require forking external
commands like ls(1) and wc(1) in the first place.

[toc] | [prev] | [next] | [standalone]

#200677 — Re: question about ls

On Thu 27 Sep 2018 at 07:55:56 (-0500), Kent West wrote:
> On Tue, Sep 25, 2018 at 6:14 PM Ben Caradoc-Davies <ben@transient.nz> wrote:
> 
> > On 26/09/2018 10:55, Long Wind wrote:
> > > sorry! you're right.
> > > after checking ls manual, i find ls has option -1
> >
> > Note also that ls will behave like it has the "-1" option if its output
> > is piped to another command, even without this option. I like to use the
> > "-1" option even in this case because it is what I mean (counting
> > entries one per line).
> >
> >
> But also note the difference when using the letter "l" vs the numeral "1":
> 
> westk@westkbox:/opt$ ls -la | wc
>      7      56     321
> westk@westkbox:/opt$ ls -1a | wc
>      6       6      54
> 
> The difference is that the letter includes the total count of blocks used
> at the top of the list (adding one to the count), whereas the numeral does
> not.

But do use 1A, not 1a, if you want to know how many items are
in a folder, otherwise . and .. will be included in the count.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#200678 — Re: question about ls

On Thu, Sep 27, 2018 at 08:53:28AM -0500, David Wright wrote:
> On Thu 27 Sep 2018 at 07:55:56 (-0500), Kent West wrote:
> > westk@westkbox:/opt$ ls -la | wc
> >      7      56     321
> > westk@westkbox:/opt$ ls -1a | wc
> >      6       6      54
> 
> But do use 1A, not 1a, if you want to know how many items are
> in a folder, otherwise . and .. will be included in the count.

All of the above give the wrong answers when filenames contain newlines.
Any solution that involves printing the filenames to a stream and then
trying to parse that stream to guess how many filenames are in the stream
is a non-starter -- unless of course the stream uses NUL delimiters
instead of newlines.

Sadly, the GNU coreutils maintainers have rejected every request, even
requests with patches attached, to add a --null option to ls.  So,
ls is not suited to this task.

[toc] | [prev] | [next] | [standalone]

#200679 — Re: question about ls

On Thu 27 Sep 2018 at 09:59:58 (-0400), Greg Wooledge wrote:
> On Thu, Sep 27, 2018 at 08:53:28AM -0500, David Wright wrote:
> > On Thu 27 Sep 2018 at 07:55:56 (-0500), Kent West wrote:
> > > westk@westkbox:/opt$ ls -la | wc
> > >      7      56     321
> > > westk@westkbox:/opt$ ls -1a | wc
> > >      6       6      54
> > 
> > But do use 1A, not 1a, if you want to know how many items are
> > in a folder, otherwise . and .. will be included in the count.
> 
> All of the above give the wrong answers when filenames contain newlines.
> Any solution that involves printing the filenames to a stream and then
> trying to parse that stream to guess how many filenames are in the stream
> is a non-starter -- unless of course the stream uses NUL delimiters
> instead of newlines.
> 
> Sadly, the GNU coreutils maintainers have rejected every request, even
> requests with patches attached, to add a --null option to ls.  So,
> ls is not suited to this task.

Sure, your FAQ is an invaluable resource for scripting, especially in
a "hostile" environment. But I think one also needs to be aware of
practical commands for use at the commandline in a benign environment.
Knowing which technique is appropriate comes with experience.

One has to be aware of the limitations of all the tools one uses.
Just as ls has weaknesses, so does wc if misused. Most people assume
that -l counts the lines in a file, but actually it counts the
newlines, which matters for the last line.

But here's another plug, and there are lots more goodies there too:

https://mywiki.wooledge.org/BashFAQ/004

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#200682 — Re: question about ls

On Thu, Sep 27, 2018 at 09:59:58AM -0400, Greg Wooledge wrote:
>All of the above give the wrong answers when filenames contain newlines.
>Any solution that involves printing the filenames to a stream and then
>trying to parse that stream to guess how many filenames are in the stream
>is a non-starter -- unless of course the stream uses NUL delimiters
>instead of newlines.
>
>Sadly, the GNU coreutils maintainers have rejected every request, even
>requests with patches attached, to add a --null option to ls.  So,
>ls is not suited to this task.

Correct, find would be a better choice for programmatic use. E.g., 
something like 
find . -mindepth 1 -maxdepth 1 -printf '\n' | wc -l

ls should be considered a user interface, not an API. If ls were 
modified sufficiently to provide a rigorous programatic interface, it 
would basically become a very non-portable reimplementation of find.

Mike Stone

[toc] | [prev] | [next] | [standalone]

#200695 — Re: question about ls

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, Sep 27, 2018 at 11:03:29AM -0400, Michael Stone wrote:

[...]

> ls should be considered a user interface, not an API.

One should strive to minimize these differences, though. This is, of
course, just my opinion, but you can pry... (you know the rest ;-)

Cheers
- -- t
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlut0P0ACgkQBcgs9XrR2kaABACaAgIzkAOwWI31y1eJm04eNmBz
TYsAnj7L5beobdoit5WzMbNoqpDHoeD7
=IsdN
-----END PGP SIGNATURE-----

[toc] | [prev] | [next] | [standalone]

#200708 — Re: question about ls

On Fri, Sep 28, 2018 at 08:58:05AM +0200, tomas@tuxteam.de wrote:
>> ls should be considered a user interface, not an API.
>
>One should strive to minimize these differences, though. This is, of
>course, just my opinion, but you can pry... (you know the rest ;-)

Sure you can--you use find. There are just too many different ways 
things can fail if you use ls, and too many ways that even things people 
think will help will fail because of differences between platforms.  
Making it "kinda better" will just create more traps like those unless 
you add a lot of explicit options to request specific output--which, 
again, ends up looking like find.

Mike Stone

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.user

csiph-web