On Tue, Aug 13, 2019 at 10:23 PM Rodney W. Grimes
wrote:
> If you had followed the thread you would know that byte 1
> of the file is a 0xA, aka LF, and the dd was to rip that
> byte off the file, but the command got morphed cause I
> used a BSD iseek=1 syntax, and gnu dd does not understand
> th
> On Tue, Aug 13, 2019 at 10:47 AM Rich Shepard
> wrote:
>
> > On Tue, 13 Aug 2019, Robert Citek wrote:
> >
> > > Sounds like you used Emacs to do the equivalent of this:
> > >
> > > < hatchery_returns-2019-08-12.csv \
> > > tr -s '\r\n' '\n' |
> > > sed -e 's/, /,/g;s/,$//' \
> > >> hatchery_ret
On Tue, Aug 13, 2019 at 10:47 AM Rich Shepard
wrote:
> On Tue, 13 Aug 2019, Robert Citek wrote:
>
> > Sounds like you used Emacs to do the equivalent of this:
> >
> > < hatchery_returns-2019-08-12.csv \
> > tr -s '\r\n' '\n' |
> > sed -e 's/, /,/g;s/,$//' \
> >> hatchery_returns-2019-08-12.cleane
On Wed, 7 Aug 2019, Rich Shepard wrote:
I've been working with the developer on this and we're both out of ideas so
I'm looking for suggestions from experienced C coders here before reaching
out on LQ.
Fixed.
One argument to the return value of strftime was local_format. Changing this
to form
On Tue, 13 Aug 2019, Johnathan Mantey wrote:
I'm guessing Xdefaults is winning. Try removing the value there and try the
alist method.
Johnathan,
I set the width/height values the same in Xdefaults and .emacs. If Xdefaults
overrides what's in the emacs file I'll wait until tomorrow since I'll
I'm guessing Xdefaults is winning. Try removing the value there and try the
alist method.
On Tue, Aug 13, 2019 at 11:22 AM Rich Shepard
wrote:
> On Tue, 13 Aug 2019, Johnathan Mantey wrote:
>
> > From emacswiki I found the initial-frame-alist and default-frame-alist
> > variables.
> > I added a
On Tue, 13 Aug 2019, Johnathan Mantey wrote:
From emacswiki I found the initial-frame-alist and default-frame-alist
variables.
I added a single line into my .emacs file and renamed my init.el file.
(setq initial-frame-alist
'((top . 10) (left . 20) (width . 150) (height . 25)))
Johnathan
>From emacswiki I found the initial-frame-alist and default-frame-alist
variables.
I added a single line into my .emacs file and renamed my init.el file.
(setq initial-frame-alist
'((top . 10) (left . 20) (width . 150) (height . 25)))
When I launch emacs the frame changes according to the v
On Tue, 13 Aug 2019, Ali Corbin wrote:
Have you tried using X to accomplish this?
Ali,
No, I haven't.
Putting:
emacs*geometry: widthxheight[+/-off+/-off]
into ~/.Xresources or ~/.Xdefaults or where such things are read on your
computer.
Well, shame on me! Yes, ~/.Xdefaults has an emacs*ge
On Tue, Aug 13, 2019 at 9:31 AM Rich Shepard
wrote:
> I'm running emacs-26.2. My web searches for setting the initial/default
> frame size find elisp solutions for ~/.emacs, but so far all of them are
> apparently for earlier versions and use deprecated syntax. So far I've
> tried
> a half-dozen
On Tue, 13 Aug 2019, Robert Citek wrote:
Sounds like you used Emacs to do the equivalent of this:
< hatchery_returns-2019-08-12.csv \
tr -s '\r\n' '\n' |
sed -e 's/, /,/g;s/,$//' \
hatchery_returns-2019-08-12.cleaned.csv
Is that right?
Robert,
Nope.
On the command line I ran:
dd if= bs=
Sounds like you used Emacs to do the equivalent of this:
< hatchery_returns-2019-08-12.csv \
tr -s '\r\n' '\n' |
sed -e 's/, /,/g;s/,$//' \
> hatchery_returns-2019-08-12.cleaned.csv
Is that right?
Regards,
- Robert
On Tue, Aug 13, 2019 at 8:37 AM Rich Shepard
wrote:
> On Tue, 13 Aug 2019, Ri
I'm running emacs-26.2. My web searches for setting the initial/default
frame size find elisp solutions for ~/.emacs, but so far all of them are
apparently for earlier versions and use deprecated syntax. So far I've tried
a half-dozen solutions and they do either nothing or emacs tells me there's
On Tue, 13 Aug 2019, Rodney W. Grimes wrote:
iseek is the same as skip, so:
Rod,
Okay. I didn't learn that from the man page here.
Change iseek -> skip, not to seek, seek in gnu dd is == oseek. And yes,
that is the option that kills the first byte of the file.
Without skip I manually dele
> On Mon, 12 Aug 2019, Rodney W. Grimes wrote:
>
> > dd if=oldfile bs=1 iseek=1 | tr '\r' '\n' >newfile
>
> Rod,
>
> The dd version here (from GNU coreutils 8.25, 2016) does not have an iseek
> option, but it does have a seek option: seek=N skip N obs-sized blocks at
> start of output.
iseek is
> On Mon, 12 Aug 2019, Rodney W. Grimes wrote:
>
> > I think od -c does NOT output the \n.. no, looked closely at a hd of the
> > file. First byte of the file is 0xa, A LF ok, so thats odd. After that the
> > lines do appear to be seperated by 0x0d, which is CR all by itself, these
> > are NOT CR-
On Tue, 13 Aug 2019, a...@clueserver.org wrote:
Have you looked at dos2unix?
Alan,
That was the first thing I tried before writing to the list. It did nothing.
Using dd does a great (but rather slow) job.
Thanks,
Rich
___
PLUG mailing list
PLUG@pd
On Tue, 13 Aug 2019, Rich Shepard wrote:
I'll use emacs' regex search/replace to replace the EOL with \n.
Correction: it has the proper \n at the end of each long line, and following
a comma and a space. Removing spaces and EOL commas makes for nice files.
Rich
__
Have you looked at dos2unix?
> On Mon, 12 Aug 2019, Rodney W. Grimes wrote:
>
>> # tr -d "\r" < hatchery_returns-2019-08-12.csv >
>> hatchery_returns-2019-08-12.clean
>> # file hatchery_returns-2019-08-12.clean
>> hatchery_returns-2019-08-12.clean: ASCII text, with very long lines
>
> Rod,
>
> Her
On Tue, 13 Aug 2019, Rich Shepard wrote:
Do I need that option?
Answer: Nope.
Removing that option converted 12M (quickly). The file command has nothing
about line terminators. When viewed in emacs each line ends in a comma, but
it is separated from the prior line. This is seen since the firs
On Mon, 12 Aug 2019, Rodney W. Grimes wrote:
dd if=oldfile bs=1 iseek=1 | tr '\r' '\n' >newfile
Rod,
The dd version here (from GNU coreutils 8.25, 2016) does not have an iseek
option, but it does have a seek option: seek=N skip N obs-sized blocks at
start of output.
However, when I run that:
On Mon, 12 Aug 2019, Rodney W. Grimes wrote:
# tr -d "\r" < hatchery_returns-2019-08-12.csv >
hatchery_returns-2019-08-12.clean
# file hatchery_returns-2019-08-12.clean
hatchery_returns-2019-08-12.clean: ASCII text, with very long lines
Rod,
Here,
tr -d "\r" < hatchery_returns-2019-08-12.csv
On Mon, 12 Aug 2019, Rodney W. Grimes wrote:
I think od -c does NOT output the \n.. no, looked closely at a hd of the
file. First byte of the file is 0xa, A LF ok, so thats odd. After that the
lines do appear to be seperated by 0x0d, which is CR all by itself, these
are NOT CR-LF windows format
On Tue, 13 Aug 2019, tomas.kuchta.li...@gmail.com wrote:
from:
https://en.wikipedia.org/wiki/Symmetric_multiprocessing
Symmetric multiprocessing (SMP) involves a multiprocessor computer hardware and
software architecture where two or more identical processors are connected to a
single, shared m
On Mon, 12 Aug 2019, Rodney W. Grimes wrote:
My guess.. this was a browser downloaded .csv file? So line endings have
been mangled by the web.
Rodney,
Yes, these files were downloaded from the agency's web site using the
'Download' button.
Last week I downloaded the database as a single Acce
On Mon, 12 Aug 2019, Rodney W. Grimes wrote:
I am starting to think you file may not actually BE windows/dos line
formatted, but something od, your output from od -c should have lots of \r
\n sequences in it.
Rodney,
Emacs shows it as a MAC style file. I understand that Macs use only \r (CR)
from:
https://en.wikipedia.org/wiki/Symmetric_multiprocessing
Symmetric multiprocessing (SMP) involves a multiprocessor computer hardware and
software architecture where two or more identical processors are connected to a
single, shared main memory, have full access to all input and output devices
27 matches
Mail list logo